oint of view of folks who consider 3.0.0
non-viable. I think that's what Barry and Martin are saying.
Of course, the definition of "viable" is the key thing here. I'm not
picking on Raymond, but what is not viable for him will be perfectly
viable for other people. We hav
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 29, 2009, at 10:59 PM, Brett Cannon wrote:
1. Barry, who is the release manager for 3.0.1, does not like the idea
of the cruft that is being proposed removed from 3.0.1. Personally I
say we continue to peer pressure him as I think a new
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 30, 2009, at 12:53 AM, Martin v. Löwis wrote:
1. Barry, who is the release manager for 3.0.1, does not like the
idea
of the cruft that is being proposed removed from 3.0.1.
I don't think he actually said that (in fact, I think he
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 30, 2009, at 11:50 AM, Mark Dickinson wrote:
On Fri, Jan 30, 2009 at 4:03 PM, Barry Warsaw
wrote:
To clarify: cruft that should have been removed 3.0 is fine to
remove for
3.0.1, for some definition of "should have been".
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 30, 2009, at 1:56 PM, Brett Cannon wrote:
On Fri, Jan 30, 2009 at 08:03, Barry Warsaw wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 30, 2009, at 12:53 AM, Martin v. Löwis wrote:
1. Barry, who is the release manager for
;s JFDI. No release candidate.
Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSYRWa3EjvBPtnXfVAQIVpgQAo1tb/RJ81WFBJHH1GhdhtKagrB5p9MSl
U+GfnLx9mEtqBqQ9rnXaQQaPpJjvNmXc10K+8oDdwCJHSX3k66JbK4U4BOBqWgc3
0PTrdIn5/4PqfexT3HWNmH/mZCZXb36HDcE6fxW5CWxuxHbNLypBY7P52XgVJIB
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 31, 2009, at 2:43 PM, Martin v. Löwis wrote:
How about Friday February 13?
Fine with me (although next Friday (Feb 6) would work slightly better)
Feb 6 won't work for me. Would the 20th be better for you Martin?
Barry
-BEGI
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 2, 2009, at 4:48 PM, Martin v. Löwis wrote:
Fine with me (although next Friday (Feb 6) would work slightly
better)
Feb 6 won't work for me. Would the 20th be better for you Martin?
No, they are both busy days - Feb 13 is then slightly
in the tracker. FWIW, I wasn't even aware of this issue.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mai
On Jul 31, 2011, at 06:55 AM, Barry Warsaw wrote:
>On Jul 31, 2011, at 06:26 PM, Nick Coghlan wrote:
>
>>That seems very questionable - the rationale for running the test
>>suite twice by default to ensure PYC generation is working correctly
>>still holds.
>
>Agre
On Aug 09, 2011, at 08:02 AM, Georg Brandl wrote:
>I can certainly release a version with these two fixes. Question is, should
>we call it 3.2.2, or 3.2.1.1 (3.2.1p1)?
Definitely 3.2.2.
-Barry
signature.asc
Description: PGP signature
___
feels righter.
I agree that the empty string is the worst of the choices. no __file__ or
__file__=None is better.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pyt
that distros
themselves have a responsibility to ensure their #! lines are correct, for
scripts they install. Meaning, if it requires rewriting the #! line on OS
package install, so be it.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
h
tend that to Windows, as well.
Yep, agreed. It probably should also inform #! transformations that pysetup
could do.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinf
h, so we should stick with the
>precedents.
I can see the small value in the convenience, but I tend to agree with Raymond
here. I think we have to be careful about not descending into macro
obfuscation world.
-Barry
___
Python-Dev mailing list
Pyt
t that, I think it's *more* confusing to use rather than
just writing it out explicitly, Py_RETURN_NONE's historic existence
notwithstanding.
So I'd opt for #1, unless we can agree on a better color for the bikeshed.
-Barry
___
Python-Dev m
developers are preferred, but motivation
and available time is paramount. You're welcome to apply even if you're not a
Windows expert, if you have the time and ability to help out in general.
If you're interested, you can reach the team at secur...@python.org.
Cheers,
-Barry
signature.
n't think it really matters since both "file system" and
>"filesystem" appear to be in common usage.
>
>I would say +1 to "FileSystemError" -- i.e. take file system as two
>words.
My online dictionaries prefer "file system" to be t
chy to the new one? Probably pretty. ;)
What about an api that applications/libraries could use to add additional
exceptions based on other errnos they cared about? This could be consulted in
PyErr_SetFromErrno() and raised instead of IOError. Okay, yeah, that's
probably pretty dumb
th Antoine - no PEP should be necessary. A well reviewed and tested
module should do it.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python
, I would discuss whether this can be
>eliminated - but not in the PEP.
+1
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pytho
re__ module is a way to introduce accepted but
incompatible changes in a controlled way, through successive releases. It's
never been used to introduce experimental features that might be removed if
they don't work out.
Cheers,
-Barry
___
Py
semantics.
More likely, it'll be a choice between wanting Unicode 6 semantics, and "don't
care". So the PEP could include some clues as to why you'd care to use regex
instead of re.
-Barry
___
Python-Dev mailing list
Python-Dev
similar split between language changes
and stdlib changes (i.e. new modules such as regex). Probably the best thing
to do would be to allocate some 1000's to the different categories, like we
did for the 3xxx Python 3k PEPS (now largely moot though).
-Barry
___
sure it's worth it either. ;)
I think we'd need a concrete proposal and someone willing to hack the PEP0
autogen tools.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
htt
On Aug 29, 2011, at 06:40 PM, Antoine Pitrou wrote:
>I like the 3k numbers myself :))
Me too. :) But I think we've pretty much abandoned that convention for any new
PEPs. Well, until Guido announces Python 4k. :)
-Barry
signature.asc
Description: PGP s
this is the surprise factor for people
debugging and reading the code. A class method would solve that, but looks
uglier and doesn't work with existing code.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
r. Okay, yeah, that's
>> probably pretty dumb too.
>
>The problem is that behaviour becomes inconsistent accross libraries.
>I'm not sure that's very helpful to the user.
Yeah, on further reflection, let's forget those last two ideas. ;)
Okay, so here's what&#x
tion to that, but the caps lock lobby has a stranglehold
>on keyboard manufacturers.
Fight The Man with xmodmap!
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pyt
merge-mode. It has some nice keybindings and
colorizing that usually makes resolving conflicts fairly straightforward. It
also will automatically `$vcs resolve` the file when you've handled all the
conflicts.
Caveat: I use it primarily for bzr, but I think it works
m like good choices to me. Maybe the former, so we could
potentially have jythonv, etc.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Oct 06, 2011, at 05:46 PM, Éric Araujo wrote:
>Le 06/10/2011 17:31, Barry Warsaw a écrit :
>> I agree we can't use virtualenv, and shouldn't use virtualize. I'm afraid
>> that picking something cute might make it harder to discover. `pythonv` or
>> `cp
On Oct 06, 2011, at 06:04 PM, Antoine Pitrou wrote:
>On Thu, 6 Oct 2011 12:02:05 -0400
>Barry Warsaw wrote:
>>
>> >The first part is implemented in CPython; the second part needs a module
>> >name to replace virtualenv. python -m pythonv doesn’t seem right.
&g
27; is apparently Lua's project of the same name for the same purpose.
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAEBCAAGBQJOjfwcAAoJEBJutWOnSwa/JRwQALLgtxOAmI9dhgaxudZgsDS7
ZeyaKFTDp2gnteMwXPFv2KK0n1SCsCIzOj807xel8id2Mr5R4FeoBC/HmySSsbxv
2U29QxXHAl/a3p
the all-caps macro name. Something about
seeing "Py_identifier" look like a function call and having it add the magical
PyId_update local bugs me. It just looks wrong, whereas the all-caps is more
of a cultural clue that something else is going on.
-Barry
___
hould now
be merged into the default branch.
PEP 3151 will bring some much needed sanity to this part of the standard
exception hierarchy, and I for one look forward to being able to write code
directly using it, one day finally eliminating most of my `import errno`s!
Cheers,
-Barry
signatur
hould I replace "socket.error" with "OSError" (knowing that the
>> former is now an alias of the latter), or leave "socket.error" so that
>> people have less surprises when running their code with a previous
>> Python version?
>
>I
iers in C. In particular, you couldn't
>> use that approach for calling the "fileno", "read" or "write" methods.
>>
>> So I think it needs a prefix. If you don't like PyId_, let me know
>> what the prefix should be inste
le, or if, in
>what document.
>
>Currently, this very point is documented in the header file.
That's fine, if the macro is prefixed with an underscore.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Oct 14, 2011, at 04:08 PM, Martin v. Löwis wrote:
>It actually is _Py_IDENTIFIER (and was _Py_identifier).
Yep, I saw your commit to make the change. Thanks!
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-
statement
>at the same indentation level), why not just have braces everywhere?
+1
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAEBCAAGBQJOoaGfAAoJEBJutWOnSwa/ng4P/AkZvFfMIwYnX5F8ctItZhgS
nZjCpbuH1dG0JBrYwXq+A0+CPJM2fnS/UItt1Lmu464XAjs53Gyk5sc4OFR4ex07
changes can break code *somewhere*. We
don't lose by being conservative with our stable branches.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/op
licted Misc/NEWS around to consult when
manually resolving the conflicts.
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAEBCAAGBQJOuXnxAAoJEBJutWOnSwa/9iAP/03KIeGBA/3qTyyfaEhen2o/
dYXvTrabjCI9S0tcbYyU3oUpUtGX8kxjOaIklwKBxpF82CmAES96jJh+gIf/5qUX
K3aGQe3Xhr7ye
I think we should have an official pronouncement about Python 2.8, and PEPs
are as official as it gets 'round here. Thus I propose the following. If
there are no objections , I'll commit this taking the next available
number.
Cheers,
-Barry
PEP: 405
Title: Python 2.8 Release Schedu
On Nov 09, 2011, at 05:18 PM, Amaury Forgeot d'Arc wrote:
>2011/11/9 Barry Warsaw
>
>> I think we should have an official pronouncement about Python 2.8, and PEPs
>> are as official as it gets 'round here.
>>
>
>Do we need to designate a release manag
e the top hit when someone searches for "Python 2.8".
Cheers,
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.or
t;+1 for Cardinal Biggles as release manager.
Brilliant!
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/o
t, I suggest including the following new
>section just before the copyright section:
You have a very good point. I think I'd like a shorter 'serious' section
though. Let me see what I can put together.
-Barry
signature.asc
Description: PGP signature
On Nov 12, 2011, at 04:03 PM, Stephen J. Turnbull wrote:
>The sensible thing is to just sort in Unicode code point order, I
>think.
M-x sort-lines-by-unicode-point-order RET
-Barry
___
Python-Dev mailing list
Python-Dev@python.or
ude the module
name, but it doesn't explain why. I think it should (explain why).
I'd like the PEP to explain why this is a better solution than re-establishing
introspectability that was available through unbound methods.
Cheers,
-Barry
___
On Nov 19, 2011, at 12:54 AM, Antoine Pitrou wrote:
>I've added explanations for these two points. Do they satisfy your
>expectations?
Yep, thanks.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
this, but please do contact me
if you want to get involved.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
p by default.
I see the work going on in Fedora/RedHat, Debian/Ubuntu, and other
distributions as applying some positive momentum on pushing the Python
community over the tipping point for Python 3 support.
Cheers,
-Barry
signature.asc
Description: PGP signature
___
Gentoo's system in a
previous life, but I don't really know enough about them to make anything
other than general recommendations. OTOH, I think Fedora's and Debian's
experience is that separate Python 2 and Python 3 stacks is the best way to
avoid insanity fo
g really
isn't very difficult these days as we've continually automated the boring
parts. The fun part is really making the decisions about what is a
showstopper, what changes can go in at the last minute, etc. Like the
president of the USA, I just hope your hair is already gray!
-Bar
f.
Once the world is all on Python 3 we can think about removing code.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
thon.org/dev/whatsnew/index.html should be enough.
Agreed, but it's too late to change it. I look at it as the attributes of the
namedtuple being evocative of the traditional names for the digit positions,
not the assignment of those positions to Python's semantics.
-Barry
ecause you
might still have byte literals which you have to b'' prefix. Do you really
want both 'foo' and u'foo' to be unicode literals?
-1
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
ve to use u() and b(), just
>for 3.2 support.
Case in point: Ubuntu 12.04 is a long term support release, meaning 5 years of
official support on both the desktop and server. It will ship with Python 2.7
and 3.2 only.
-Barry
___
Python-Dev
n that case,
you're kind of screwed. Python 2's str type let you cheat, but not without
consequences. Those consequences are spelled "UnicodeErrors" and I'll be glad
to be rid of them.
Cheers,
-Barry
___
Python-Dev mailing list
snip-
$ python /tmp/foo.py
2 7
$ python3 /tmp/foo.py
3 2
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Dec 09, 2011, at 03:18 PM, Lennart Regebro wrote:
>On Fri, Dec 9, 2011 at 04:34, Barry Warsaw wrote:
>> Sorry, I don't understand this. What does it mean to be "str in both
>> versions"? And why would you want that?
>
>It means that it's a str, that
t for
one-codebase cross-Python code.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
efficiently in an extension module, and make that
available for older Pythons via the Cheeseshop. I now also have a few more
Python and C level compatibility hacks that could make it into such a module.
-Barry
___
Python-Dev mailing list
Python-Dev@p
we already have that in PyObject_Str(), or in Python 2,
PyObject_Unicode()?
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
all when it comes to Python 3 porting
yet. ;)
Sometimes, one code base works better, other times 2to3 works well. I tend to
use the latter on pure-Python setuptools-based projects, and the former on
projects with C extensions, autoconf-based libraries.
-Barry
__
On Dec 14, 2011, at 08:38 AM, Nick Coghlan wrote:
>String translation is also an open question. For some codebases, you
>want both u"" and "" to translate to a Unicode "" (either in Py3k or
>via the future import)
I have a fixer for this:
http://bazaar.lau
usually cited as the
reason.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
where the submission misses
the important consistency points, but not to hold up merging the changes
because of that. You want to educate and motivate so that the next submission
comes closer to our standards. The core dev who commits the change can clean
up style issues
ing and just code.
+1
The other reason why style guides exist is to give contributors some sense of
what they should shoot for. I've worked on existing code bases where there's
so little consistency I can't tell what the author's preferences are even if I
w
On Jan 02, 2012, at 06:38 PM, Georg Brandl wrote:
>I wouldn't expect too much -- they seem rather keen on cheap laughs:
>
>http://twitter.com/#!/bk3n/status/152068096448921600/photo/1/large
Heh, so yeah, it won't be me conta
urself if
you want to follow the progress.
Cheers,
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/optio
in Debian (untested).
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Jan 05, 2012, at 01:46 PM, Mark Shannon wrote:
>2. Submit a bug report for each "failing" test separately?
I'm sure it will be a pain, but this is really the best thing to do.
-Barry
___
Python-Dev mailing list
Python-D
ion about the default, although I'd argue for the above
default approach for Debian/Ubuntu.
>Any such logic here also suggests the need for an attribute in the sys module
>so that you can verify the behavior.
That would be read-only though, right?
-Barry
ith no
>bells and whistles to switch it off or the like.
I like David Malcolm's suggestion, but I have no problem applying it to 3.3,
enabled by default with no way to turn it off. The off-by-default on-switch
policy for stable releases would
On Jan 05, 2012, at 10:40 PM, Christian Heimes wrote:
>Hey Barry, stop stealing my ideas! :) I've argued for these default
>settings for days.
:)
>I've suggested the env var PYRANDOMHASH. It's easy to set env vars in
>Apache. For example Debian/Ubuntu has /etc/apache
le digit"
respectively, regardless of Python's interpretation of them.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
reak too much code and organizations will have to
>roll back the release or do extensive testing before installing a bugfix
>release -- exactly what we *don't* want for those.
+1
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
htt
ault behavior for stable
releases, because it's the right thing to do for our users.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pyt
r mush under chronologically arranged pictures of
BDFLs Van Rossum, Peterson, and Van Rossum.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
changed.
So I still think we should ditch the paranoia about dictionary order changing,
and fix this without counting. A little bit of paranoia could creep back in
by disabling the hash fix by default in stable releases, but I think it would
be f
nting was added. It's also a
bug that any number of changes in the environment, or OS vendor deployment,
could have triggered.
-1 for collision counting.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinf
response (or whatever's appropriate for the
>protocol being attacked).
Let's just be clear about it: this exception is new public API. Changing
dictionary order is not.
For me, that comes down firmly on the side of the latter rather than the
former for
>> Type: Standards Track
>> Content-Type: text/x-rst
>> Created: 26-Jan-2012
>> Python-Version: 3.3
>> Post-History:
>
>BTW, I don't really think this needs a PEP.
I think a PEP is appropriate, but the title is certainly misnamed.
-Barry
_
ore eyeballs (and hopefully more feedback, therefore), my
>only response to this is: if it doesn't get eyeballs on PyPi I don't think
>there's a great enough need to justify it in the stdlib.
I agree with everything Alex said here.
-Barry
signature.asc
Description: PGP sign
On Jan 27, 2012, at 10:48 PM, Antoine Pitrou wrote:
>On Fri, 27 Jan 2012 16:10:51 -0500
>Barry Warsaw wrote:
>>
>> I'm -1 on this as well. It just feels like the completely wrong way to
>> stabilize an API, and I think despite the caveats that are explicit in
>
message that we can clearly articulate to
users of the library. I think most people will see it in the module
documentation, just use it, and then complain when it's gone.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mai
folks developing on that
platform could just use the distro package and ignore __preview__.
If that's acceptable, then maybe it should be explicitly so in the PEP.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-D
ot add anything to __preview__ without
consent (and contributor agreement) of the upstream developers.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/o
e their success, and we have the guts to end the experiment if it
doesn't work out.
Of course, if it's a resounding success, then that's fantastic too.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
it in the stdlib as regex and keep it there. Any other
>solution will just cause too much anxiety.
+1
What does the PEP give you above this "simple as possible" solution?
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://ma
years in production code to
shake things out. I often think a generic answer to "did I get the API right"
could be "no, but it's okay" :)
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
On Jan 30, 2012, at 12:03 PM, Brett Cannon wrote:
>I think that would be good. And I would even argue we remove support for
>turning it off to force people to no longer lean on dict ordering as a
>crutch (in 3.3 obviously).
Yes, please
lly better with a
keyword-only argument, but not much.
I haven't read the whole thread so maybe this is a stupid question, but why
can't we add a datetime-compatible higher precision type that hides all the
implementation details?
-Barry
___
Pytho
rmind, let's see the whole thing after all
raise e from __NoCause__
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
g __cause__ to
Ellipsis to mean use __context__.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/py
ive stable branches agree it's best to get these coordinated security
releases out as soon as possible.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
x27;d be happy to release a 2.6.8 rc next week.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
o
run my test, but my users wouldn't). But Bazaar or Mercurial users would care
a lot.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
2201 - 2300 of 2826 matches
Mail list logo
