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
___
Python-Dev
On Aug 11, 2011, at 04:39 PM, Éric Araujo wrote:
>> * XXX what is the __file__ of a "pure virtual" package? ``None``?
>> Some arbitrary string? The path of the first directory with a
>> trailing separator? No matter what we put, *some* code is
>> going to break, but the last choice might
On Aug 12, 2011, at 01:10 PM, Nick Coghlan wrote:
>1. Accept the reality of that situation, and propose a mechanism that
>minimises the impact of the resulting ambiguity on end users of Python
>by allowing developers to be explicit about their target language.
>This is the approach advocated in PE
On Aug 12, 2011, at 01:34 PM, R. David Murray wrote:
>True, but I think that is orthogonal to the purposes of the PEP, which
>is about supporting writing of system independent scripts that are *not*
>provided by the distribution (or installed via packaging). And PEP 397
>aims to extend that to Wi
On Aug 15, 2011, at 05:46 AM, Raymond Hettinger wrote:
>I don't think that is worth it. There is some value to keeping the API
>consistent with the style that has been used in the past. So, I vote for
>Py_RETURN_NOTIMPLEMENTED. There's no real need to factor this any further.
>It's not hard and
On Aug 16, 2011, at 08:32 AM, Nick Coghlan wrote:
>Indeed, this entire discussion was started by the extension of the
>Py_RETURN_NONE idiom to also adopt Py_RETURN_NOTIMPLEMENTED.
>
>If the idiom is to be extended at all, why stop there? Why not cover
>the Py_RETURN_TRUE and Py_RETURN_FALSE cases
Hi folks,
The Python security team is a small group of core Python developers who triage
and respond to vulnerability reports sent to secur...@python.org. We get all
kinds of reports, for which we try to provide guidance and feedback, review
patches, etc. Python being as secure as it is, traffic
On Aug 23, 2011, at 08:39 PM, Ross Lagerwall wrote:
>> When reviewing the PEP 3151 implementation (*), Ezio commented that
>> "FileSystemError" looks a bit strange and that "FilesystemError" would
>> be a better spelling. What is your opinion?
>
>I don't think it really matters since both "file sy
I am sending this review as the BDFOP for PEP 3151. I've read the PEP and
reviewed the python-dev discussion via Gmane. I have not reviewed the hg
branch where Antoine has implemented it.
I'm not quite ready to pronounce, but I do have some questions and comments.
First off, thanks to Antoine fo
On Aug 27, 2011, at 10:36 PM, Nadeem Vawda wrote:
>I talked to Antoine about this on IRC; he didn't seem to think a PEP would be
>necessary. But a summary of the discussion on the tracker issue might still
>be a useful thing to have, given how long it's gotten.
I agree with Antoine - no PEP shoul
On Aug 27, 2011, at 07:11 PM, Martin v. Löwis wrote:
>A PEP should IMO only cover end-user aspects of the new re module.
>Code organization is typically not in the PEP. To give a specific
>example: you mentioned that there is (near) code duplication
>MRAB's module. As a reviewer, I would discuss w
On Aug 26, 2011, at 05:25 PM, Dan Stromberg wrote:
>from __future__ import is an established way of trying something for a while
>to see if it's going to work.
Actually, no.
The documentation says:
-snip snip-
__future__ is a real module, and serves three purposes:
* To avoid confusing
On Aug 27, 2011, at 01:15 PM, Ben Finney wrote:
>My question is directed more to M-A Lemburg's passage above, and its
>implicit assumption that the user understand the changes between
>“Unicode 2.0/3.0 semantics” and “Unicode 6 semantics”, and how their own
>needs relate to those semantics.
More
On Aug 29, 2011, at 11:03 AM, Dirkjan Ochtman wrote:
>Also, this PEP makes me wonder if there should be a way to distinguish
>between language PEPs and (CPython) implementation PEPs, by adding a
>tag or using the PEP number ranges somehow.
I've thought about this, and about a similar split betwee
On Aug 29, 2011, at 06:55 PM, Stefan Behnel wrote:
>These things tend to get somewhat clumsy over time, though. What about a
>stdlib change that only applies to CPython for some reason, e.g. because no
>other implementation currently has that module? I think it's ok to make a
>coarse-grained dist
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 signature
___
On Aug 24, 2011, at 12:51 PM, Nick Coghlan wrote:
>On Wed, Aug 24, 2011 at 9:57 AM, Antoine Pitrou wrote:
>> Using IOError.__new__ is the easiest way to ensure that all code
>> raising IO errors takes advantage of the errno mapping. Otherwise you
>> may get APIs raising the proper subclasses, and
On Aug 24, 2011, at 01:57 AM, Antoine Pitrou wrote:
>> One guiding principle for me is that we should keep the abstraction as thin
>> as possible. In particular, I'm concerned about mapping multiple errnos
>> into a single Error. For example both EPIPE and ESHUTDOWN mapping to
>> BrokePipeError,
On Sep 06, 2011, at 03:42 PM, Fred Drake wrote:
>On Tue, Sep 6, 2011 at 3:36 PM, Steven D'Aprano wrote:
>> pERSONNALLY, i THINK THAT A SWAPCASE COMMAND IS ESSENTIAL FOR TEXT EDITOR
>> APPLICATIONS, TO AVOID THOSE LITTLE cAPS lOCK ACCIDENTS.
>
>There's a better solution to that, but the caps lock
On Sep 29, 2011, at 12:07 PM, Victor Stinner wrote:
> I disabled the merge GUI: I lose a lot of work because I'm unable to use a
> GUI to do merge, I don't understand what are the 3 versions of the same file
> (which one is the merged version!?)
Emacs users should look at smerge-mode. It has som
On Oct 06, 2011, at 04:12 PM, Éric Araujo wrote:
>I started to play with virtualenv recently and wondered about the status
>of the similar feature in 3.3 (cpythonv). The last thread mentioned two
>bugs; one has been fixed since.
>
>Apart from the implicit vs. explicit download of distribute, are
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Oct 06, 2011, at 12:33 PM, Carl Meyer wrote:
>I still think 'venv' is preferable to any of the other options proposed
>thus far.
It's also nicely unique for googling. Funnily enough, the top hit right now
for 'venv' is apparently Lua's project
On Oct 11, 2011, at 02:36 PM, Hrvoje Niksic wrote:
>On 10/08/2011 04:54 PM, "Martin v. Löwis" wrote:
>> tmp = PyObject_CallMethod(result, "update", "O", other);
>>
>> would be replaced with
>>
>>PyObject *tmp;
>>Py_identifier(update);
>>...
>>tmp = PyObject_Ca
As the BDFOP for PEP 3151, I hereby accept it for inclusion into Python 3.3.
Congratulations to Antoine for producing a great PEP that has broad acceptance
in the Python development community, with buy-in from all the major
implementations of Python. Antoine's branch is ready to go and it should
On Oct 12, 2011, at 10:24 AM, Benjamin Peterson wrote:
>2011/10/12 Antoine Pitrou :
>> I'd like some advice on what the best path is in cases such as:
>>
>> A :exc:`socket.error` is raised for errors from the call
>> to :func:`inet_ntop`.
>>
>> Should I replace "socket.error" with "OSError" (k
On Oct 13, 2011, at 03:23 PM, Antoine Pitrou wrote:
>Py_CONST_STRING or Py_IDENTIFIER would be fine with me. Given that
>everything else uses "Id" in their name, Py_IDENTIFIER is probably better?
I agree that either is fine, with a slight preference for Py_IDENTIFIER for
the same reasons.
>> Or
On Oct 13, 2011, at 08:08 PM, Martin v. Löwis wrote:
>>> Py_CONST_STRING or Py_IDENTIFIER would be fine with me. Given that
>>> everything else uses "Id" in their name, Py_IDENTIFIER is probably better?
>>
>> I agree that either is fine, with a slight preference for Py_IDENTIFIER for
>> the same
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-Dev@p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Oct 21, 2011, at 12:40 PM, Tres Seaver wrote:
>Hmm, PEP 7 doesn't show any example of the one-liner exception. Given
>that it tends to promote errors, particularly among
>indentation-conditioned Python programmers (adding another statement
>at t
On Oct 31, 2011, at 06:23 PM, Éric Araujo wrote:
>I thought that patches that clean up code but don’t fix actual bugs were
>not done in stable branches. Has this changed?
I hope not. Sure, if they fix actual bugs, that's fine, but as MvL often
points out, even innocent looking changes can break
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Nov 08, 2011, at 04:49 PM, Jesus Cea wrote:
>When merging from 3.2 to 3.3 "Misc/NEWS" always conflicts (lately).
>Instead of copy&paste the test manually between versions, has anybody
>a better workflow?.
Does Mercurial support custom merge plug
le
Version: $Revision$
Last-Modified: $Date$
Author: Barry Warsaw
Status: Final
Type: Informational
Content-Type: text/x-rst
Created: 2011-11-09
Python-Version: 2.8
Abstract
This document describes the development and release schedule for Python 2.8.
Release Schedule
T
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
On Nov 09, 2011, at 11:18 AM, Benjamin Peterson wrote:
>I don't know why this PEP is necessary, but I think a more appropriate
>title would be "2.x is in maintenance only mode".
Okay, it's a little tongue-in-cheek, but the practical reason is that I want
it to be the top hit when someone searches
On Nov 09, 2011, at 08:58 PM, Paul Moore wrote:
>I see why people feel that something more precise and/or formal would
>get the message across better, but the mildly tongue-in-cheek tone
>isn't really inappropriate for a language named after Monty Python :-)
*Thank you* :)
>+1 for Cardinal Biggl
On Nov 10, 2011, at 08:58 AM, Nick Coghlan wrote:
>Now you need to persuade Vinay to let you trade PEP numbers with the
>pyvenv PEP. Having an unrelease schedule as PEP 404 is too good an
>opportunity to pass up :)
Brilliant suggestion! Vinay? :)
>Getting boring for a moment, I suggest includin
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.org
http://mail.python.
On Nov 18, 2011, at 09:14 PM, Antoine Pitrou wrote:
>I haven't seen any strong objections, so I would like to go ahead and
>commit PEP 3155 (*) soon. Is anyone against it?
>
>(*) "Qualified name for classes and functions"
>http://www.python.org/dev/peps/pep-3155/
I'm still not crazy about the
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/listinfo/python-
On Nov 22, 2011, at 02:15 PM, Stefan Behnel wrote:
>Well, Py3 still has a lot to catch up in terms of wide spread distribution
>compared to Py2.x, and new users will usually start using the most up to date
>release, which will soon be 3.3.
>
>Besides, 3.3 has received various optimisations that ma
On Nov 22, 2011, at 09:13 AM, Toshio Kuratomi wrote:
>For Fedora (and currently, Red Hat is based on Fedora -- a little more about
>that later, though), we have parallel python2 and python3 stacks.
Debian (and thus Ubuntu) also has separate Python 2 and 3 stacks. In general,
if you have a Python
On Nov 22, 2011, at 06:10 PM, Xavier Morel wrote:
>It's definitely not going to replace the Apple-provided Python out of the
>box, so setting `python` to a python3 is not going to happen.
Nor should it! PEP 394 attempts to codify the Python project's
recommendations for what version 'python' (e.
On Nov 22, 2011, at 07:50 PM, Larry Hastings wrote:
>I've volunteered to be the Release Manager for Python 3.4. The FLUFL has
>already given it his Sloppy Wet Kiss Of Approval,
I think you mistook that for my slackjaw droolings when you repeatedly ignored
my warnings to run as far from it as pos
On Nov 28, 2011, at 03:36 PM, Petri Lehtinen wrote:
>Raymond Hettinger wrote:
>> That may serve a notion of tidyness or somesuch but in reality it is
>> a PITA for users making it more difficult to upgrade python versions
>> and making it more difficult to use published recipes.
>
>I'm strongly ag
On Nov 29, 2011, at 01:59 PM, Antoine Pitrou wrote:
>Well, that's why I think the version number components are not
>correctly named. I don't think any of the 2.x or 3.x releases can be
>called "minor" by any stretch of the word. A quick glance at
>http://docs.python.org/dev/whatsnew/index.html sh
On Dec 08, 2011, at 12:08 AM, Chris McDonough wrote:
> from __future__ import unicode_literals
> a = 'foo'
I agree this is an annoying thing to have to change when supporting a
dual-Python-version codebase, but it's not the most annoying. print-functions
are a little more painful to switch b
On Dec 08, 2011, at 11:01 AM, Vinay Sajip wrote:
>Well, if 3.2 remains in use for a longish time, then it is relevant, in the
>broader context, isn't it? We know how conservative Linux distributions can
>be with their Python releases - although most are still releasing 2.x as
>their system Python
On Dec 09, 2011, at 03:50 AM, Lennart Regebro wrote:
>One reason is that you need to be able to say "This should be str in
>Python 2, and binary in Python 3, that should be Unicode in Python 2
>and str in Python 3, and that over there should be str in both
>versions", and the future import doesn't
On Dec 08, 2011, at 06:53 PM, Guido van Rossum wrote:
>Are you saying that with that future import, b"..." is still a Unicode
>literal?
No, the future import has no impact on b-strings.
-snip snip-
from __future__ import print_function
import sys
print(sys.version_info.major, sys.version
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
On Dec 09, 2011, at 09:20 AM, Martin v. Löwis wrote:
>One use case (and the only one I'm aware of) is to pass keyword
>parameters. Python 2 insists that they are str (and doesn't accept
>unicode), Python 3 insists that they are str (and doesn't accept bytes).
>
>This is fairly uncommon as a proble
On Dec 09, 2011, at 06:09 PM, Nick Coghlan wrote:
>Given that WSGI 1.0.1 is defined in terms of native strings and restoring
>u'' support allows that to be expressed clearly in a shared codebase, I at
>least understand the point of the suggestion now. I'm not quite convinced
>restoring u'' is the
On Dec 09, 2011, at 07:12 PM, Nick Coghlan wrote:
>Isn't it basically just exposing a C level version of the unicode()
>builtin's behaviour? While I agree the name could be better (and
>PyUnicode_AsExactUnicode would certainly work), why make it private?
Don't we already have that in PyObject_Str
On Dec 13, 2011, at 05:24 PM, Antoine Pitrou wrote:
>On Tue, 13 Dec 2011 15:28:31 +0100
>"Laurence Rowe" wrote:
>>
>> The approach that most people seem to have settled on for porting
>> libraries to Python 3 is to make a single codebase that is compatible with
>> both Python 2 and Python 3,
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.launchpad.net/~barry/flufl.i18n/devel/view/
On Dec 21, 2011, at 07:16 AM, Chris Withers wrote:
>What's the general consensus on supporting Python 2.5 nowadays?
FWIW, Ubuntu dropped 2.5 quite a while ago. The next LTS (long term support)
release in April 2012 will have only Python 2.7 (and 3.2). The currently
in-development next Debian re
On Jan 02, 2012, at 06:35 PM, Georg Brandl wrote:
>Exactly. Especially for reviews of patches from non-core people, we
>should exercise a lot of restraint: as the committers, I think we can be
>expected to bite the sour bullet and apply our uniform style (such as
>it is).
>
>It is tiresome, if not
On Jan 02, 2012, at 02:08 PM, Guido van Rossum wrote:
>The irony is that style guides exist to *avoid* debates like this. Yes, the
>choices are arbitrary. Yes, tastes differ. Yes, there are exceptions to the
>rules. But still, once a style rule has been set, the idea is to stop
>debating and just
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 contacting them.
-Barry
___
Pytho
On Dec 31, 2011, at 04:56 PM, Guido van Rossum wrote:
>Is there a tracker issue yet? The discussion should probably move there.
I think the answer to this was "no"... until now.
http://bugs.python.org/issue13703
Proposed patches should be linked to this issue now. Please nosy yourself if
you w
On Jan 04, 2012, at 02:59 AM, Antoine Pitrou wrote:
>Well what if /dev/urandom is unavailable because the program is run
>e.g. in a chroot?
>(or is /dev/urandom still available in a chroot?)
It is (apparently) in an schroot in Ubuntu, so I'd guess it's also available
in Debian (untested).
-Barry
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-Dev@python.org
http://mail.pyth
On Jan 05, 2012, at 02:33 PM, David Malcolm wrote:
>We have similar issues in RHEL, with the Python versions going much
>further back (e.g. 2.3)
>
>When backporting the fix to ancient python versions, I'm inclined to
>turn the change *off* by default, requiring the change to be enabled via
>an env
On Jan 05, 2012, at 08:35 PM, Paul Moore wrote:
>Uh, surely no-one is suggesting backporting to "ancient" versions? I
>couldn't find the statement quickly on the python.org website (so this
>is via google), but isn't it true that 2.6 is in security-only mode
>and 2.5 and earlier will never get the
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/apache2/envvars.
For consistency,
On Jan 10, 2012, at 09:03 PM, Anthony Kong wrote:
>I don't find 'major' and 'minor' confusing too. Maybe because it is the
>designation used in linux community for years.
Neither do I. I read them as aliases for "leftmost digit" and "middle digit"
respectively, regardless of Python's interpretat
On Jan 13, 2012, at 05:38 PM, Guido van Rossum wrote:
>On Fri, Jan 13, 2012 at 5:17 PM, Antoine Pitrou wrote:
>
>> Breaking due to variable hashing is deterministic: you notice it as
>> soon as you upgrade (and then you use PYTHONHASHSEED to disable
>> variable hashing). That seems better than un
On Jan 18, 2012, at 08:19 AM, Martin v. Löwis wrote:
>My concern is not about breaking doctests: this proposal will also break
>them. My concern is about applications that assume that hash(s) is
>stable across runs, and we do have reports that it will break
>applications.
I am a proponent of doct
On Jan 19, 2012, at 12:17 PM, Antoine Pitrou wrote:
>The main problem I see with this is that Python 3 was a big
>disruptive event for the community, and calling a new version "Python
>4" may make people anxious at the prospect of compatibility breakage.
s/was/is/
The Python 3 transition is ongo
On Jan 20, 2012, at 01:50 PM, Victor Stinner wrote:
>Counting collision doesn't solve this case, but it doesn't make the
>situation worse than before. Raising quickly an exception is better
>than stalling for minutes, even if I agree than it is not the best
>behaviour.
ISTM that adding the possib
On Jan 20, 2012, at 03:18 PM, Nick Coghlan wrote:
>On Fri, Jan 20, 2012 at 2:54 PM, Carl Meyer wrote:
>> I don't have the expertise to speak otherwise to the alternatives for
>> fixing the collisions vulnerability, but I don't believe it's accurate
>> to presume that Django would not want to fix
On Jan 20, 2012, at 03:15 PM, Nick Coghlan wrote:
>With the 1000 collision limit in place, the attacker sends their
>massive request, the affected dict quickly hits the limit, throws an
>unhandled exception which is then caught by the web framework and
>turned into a 500 Error response (or whateve
On Jan 26, 2012, at 10:54 PM, Benjamin Peterson wrote:
>2012/1/26 Ethan Furman :
>> PEP: XXX
>> Title: Interpreter support for concurrent programming
>
>mm?
>
>> Version: $Revision$
>> Last-Modified: $Date$
>> Author: Ethan Furman
>> Status: Draft
>> Type: Standards Track
>> Content-Type: text/x-
On Jan 27, 2012, at 05:26 PM, Alex wrote:
>I'm -1 on this, for a pretty simple reason. Something goes into __preview__,
>instead of it's final destination directly because it needs feedback/possibly
>changes. However, given the release cycle of the stdlib (~18 months), any
>feedback it gets can't
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
>
On Jan 27, 2012, at 10:02 PM, Paul Moore wrote:
>Agreed entirely. We need a way to signal somehow that a module is
>being seriously considered for stdlib inclusion. That *would* result
>in more uptake, and hence more testing and feedback.
I'm just not convinced that's a message that we can clearl
On Jan 28, 2012, at 11:37 AM, Nick Coghlan wrote:
>Then the stdlib docs for that module (while it is in __preview__)
>would say "If you are able to easily use third party packages, package
> offers this API for multiple Python versions with stronger API
>stability guarantees. This preview version
On Jan 28, 2012, at 11:27 AM, Nick Coghlan wrote:
>* for an intranet web service deployment where due diligence adds
>significant overhead to any use of third party packages
Which really means that *we* are assuming the responsibility for this due
diligence. And of course, we should not add anyt
On Jan 28, 2012, at 11:13 AM, Nick Coghlan wrote:
>Really, regex is the *reason* this PEP exists: we *know* we need to
>either replace or seriously enhance "re" (since its Unicode handling
>isn't up to scratch), but we're only *pretty sure* adding "regex" to
>the stdlib is the right answer. Adding
On Jan 28, 2012, at 09:15 AM, Guido van Rossum wrote:
>So I do not support the __preview__ package. I think we're better off
>flagging experimental modules in the docs than in their name. For the
>specific case of the regex module, the best way to adoption may just
>be to include it in the stdlib
On Jan 28, 2012, at 07:29 PM, Guido van Rossum wrote:
>Finally, if you really want to put warnings in whenever an
>experimental module is being used, make it a silent warning, like
>SilentDeprecationWarning. That allows people to request more strict
>warnings without unduly alarming the users of a
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!
-Barry
___
Pyt
On Feb 02, 2012, at 11:07 PM, Nick Coghlan wrote:
>Yup, that's why your middle-ground approach didn't make any sense to
>me. Returning Decimal when a flag is set to request high precision
>values actually handles everything (since any epoch related questions
>only arise later when converting the d
On Feb 03, 2012, at 08:52 AM, Ethan Furman wrote:
>Not sure I'll ever use it this way, but:
>
>try:
> try:
> raise IndexError()
> except:
> raise CustomError() from None
>except CustomError as e:
> # nevermind, let's see the whole thing after all
> raise e from Ellipsis
In that co
On Feb 03, 2012, at 10:20 AM, Guido van Rossum wrote:
a = ...
>
>Is likewise cute but not very informative. But it is valid syntax.
FWIW (probably not much at this point), it's not the syntax I have a problem
with, but the semantics as described in the PEP of setting __cause__ to
Ellipsis to
On Feb 05, 2012, at 02:25 PM, Benjamin Peterson wrote:
>The reason 3.2.3 is so soon is the need to patch the hash collision attack.
Also remember that we are coordinating releases between several versions of
Python for this issue, some of which are in security-only mode. The RMs of
the active st
On Feb 06, 2012, at 07:11 AM, Georg Brandl wrote:
>Well, one way to do it would be to release a rc now-ish, giving the community
>time to test it, and to already use it productively in critical cases, and
>release the final with the OSX fixes after/at PyCon.
That could work well. I'd be happy to
Brett, thanks for persevering on importlib! Given how complicated imports are
in Python, I really appreciate you pushing this forward. I've been knee deep
in both import.c and importlib at various times. ;)
On Feb 07, 2012, at 03:07 PM, Brett Cannon wrote:
>One is maintainability. Antoine menti
On Feb 07, 2012, at 09:19 PM, Paul Moore wrote:
>One question here, I guess - does the importlib integration do
>anything to make writing on-demand import mechanisms easier (I'd
>suspect not, but you never know...) If it did, then performance issues
>might be somewhat less of a sticking point, as
On Feb 13, 2012, at 01:28 AM, Victor Stinner wrote:
>I'm still waiting for Nick Coghlan and Guido van Rossum for their
>decision on the PEP.
Thanks for continuing to work on this Victor. I agree with the general
motivation behind the PEP, and appreciate your enthusiasm for improving Python
here.
On Feb 13, 2012, at 12:31 PM, Nick Coghlan wrote:
>I think Antoine makes a good point about ease of introspection when
>you have multiple versions in the same series installed, so I'd be
>fine with:
>- updating the PEP recommendation to say that either form of link is
>fine (with hard links margin
On Feb 14, 2012, at 12:38 PM, Nick Coghlan wrote:
>> One other thing I'd like to see the PEP address is a possible migration
>> strategy to python->python3. Even if that strategy is "don't do it, man!".
>> IOW, can a distribution change the 'python' symlink once it's pointed to
>> python2? What
On Feb 13, 2012, at 07:33 PM, Victor Stinner wrote:
>Oh, I forgot to mention my main concern about datetime: many functions
>returning timestamp have an undefined starting point (an no timezone
>information ), and so cannot be converted to datetime:
> - time.clock(), time.wallclock(), time.monoton
I think I will just state my reasoning one last time and then leave it to the
BDFL or BDFOP to make the final decision.
Victor on IRC says that there is not much difference between Decimal and
timedelta, and this may be true from an implementation point of view. From a
cognitive point of view, I
On Feb 15, 2012, at 10:23 AM, Nick Coghlan wrote:
>What should timedelta.total_seconds() return to avoid losing nanosecond
>precision? How should this be requested when calling the API?
See, I have no problem having this method return a Decimal for high precision
values. This preserves the valu
On Feb 15, 2012, at 10:11 AM, Martin v. Löwis wrote:
>I think improving datetime needs to go in two directions:
>a) arbitrary-precision second fractions. My motivation for
> proposing/supporting Decimal was that it can support arbitrary
> precision, unlike any of the alternatives (except for u
On Feb 15, 2012, at 09:20 AM, Guido van Rossum wrote:
>Does this need a pronouncement? Worrying about the speed of symlinks
>seems silly, and exactly how the links are created (hard or soft,
>chaining or direct) should be up to the distro; our own Makefile
>should create chaining symlinks just so
2101 - 2200 of 2704 matches
Mail list logo
