Sent from my iPhone
> On 15 Sep 2019, at 23:25, Tim Peters wrote:
>
> [Tim]
>> While python-dev has several "official" moderators, best I can tell
>> I'm the only one who has reviewed these messages for years.
>
> I should clarify that! That's not meant to be a dig at the other
> moderators
Sent from my iPhone
> On 22 Jun 2019, at 08:15, Karthikeyan Singaravelan
> wrote:
>
> From Python 3.6 the order of keyword arguments to a function is preserved. In
> https://bugs.python.org/issue21256 the order of keyword arguments for
> unittest.mock's repr were sorted to return determini
> On 28 Apr 2019, at 22:55, Chris Withers wrote:
>
>> On 28/04/2019 22:21, Robert Collins wrote:
>> Thank you!
>
> Thank me when we get there ;-) Currently in Dec 2018 with a wonderful Py2
> failure:
>
> ==
> ERROR: test_au
On Wednesday, 15 July 2015, Robert Collins
wrote:
> On 15 July 2015 at 12:59, Nick Coghlan wrote:
>>
>> There is zero urgency here, so nothing needs to change for 3.5.
>> Robert's plan is a fine one to propose for 3.6 (and the PyPI mock
>> backport).
>
> Right - the bad API goes back to the very
On Tuesday, 14 July 2015, Christie Wilson wrote:
>> If people do misspell it, I think they do learn not to in after it
happens a few times.
>
> Unless the line silently executes and they don't notice the mistake for
years :'(
Indeed. This has been a problem with mock, misspelled (usually
misremem
d be super nice for us to complete
> this support. At the very least it would make unicode strings and bytestrings
> correspond directly to how they are represented in Java, so that will be a
> nice cleanup.
> * Release schedule: we will get there at some point!
>
>
> On Sun,
On 18/03/14 16:44, Antoine Pitrou wrote:
Hello Xavier,
It is not obvious your message is appropriate for python-dev. It looks
like mere advertising; if it is not, please explain.
To clarify what this mailing-list is about: "On this list the key
Python developers discuss the future of the l
On 10 Oct 2013, at 01:53, Eric Snow wrote:
> Registration is now open for PyCon US 2014. Are there any plans yet
> for the language summit? Just the day (e.g. Thursday April 10) will
> suffice. Then we can make arrangements appropriately. Thanks.
Sorry for the late reply. Yes there will be
On 6 October 2013 11:45, georg.brandl wrote:
> http://hg.python.org/cpython/rev/942b9420e7e9
> changeset: 86065:942b9420e7e9
> branch: 3.3
> parent: 86062:6ced4fb4f711
> user:Georg Brandl
> date:Sun Oct 06 12:46:13 2013 +0200
> summary:
> PythonCAD is now on PyQt, u
On 3 Oct 2013, at 12:05, Nick Coghlan wrote:
>
> On 3 Oct 2013 06:00, "Victor Stinner" wrote:
> >
> > I don't remember where, but I remember that I also saw things like
> > "str=str, len=len, ...". So you keep the same name, but you use fast
> > local lookups instead of slow builtin lookups.
>
Sent from my iPhone
On 3 Aug 2013, at 19:07, "R. David Murray" wrote:
> On Sat, 03 Aug 2013 10:27:30 -0400, Matt McClure
> wrote:
>> Michael Foord voidspace.org.uk> writes:
>>> On 2 Aug 2013, at 19:19, Antoine Pitrou pitrou.net> wrote:
>>>>
Sent from my iPhone
On 2 Aug 2013, at 19:19, Antoine Pitrou wrote:
> Le Fri, 2 Aug 2013 18:13:13 +0300,
> Michael Foord a écrit :
>>
>> On 2 Aug 2013, at 14:51, Matt McClure
>> wrote:
>>
>>> It seems unittest.TestSuite holds references to unittes
Sent from my iPhone
On 2 Aug 2013, at 14:51, Matt McClure wrote:
> It seems unittest.TestSuite holds references to unittest.TestCase instances
> after the test runs, until the test suite finishes. In a large suite, where
> the TestCase instances consume memory during execution, that can lead
On 5 Jul 2013, at 12:26, Łukasz Langa wrote:
> On 5 lip 2013, at 12:07, Martin v. Löwis wrote:
>
>> I wonder why you need to figure out the signatures in advance.
>> Can you just wait until the function is actually used, and then
>> process the parameters as you get them?
>>
>
> My guess is
On 5 Jul 2013, at 12:07, "Martin v. Löwis" wrote:
> Am 05.07.13 11:23, schrieb Michael Foord:
>> I've also lamented the death of bound methods in Python 3 for mock
>> "autospeccing". Autospec introspects objects and provides mock
>> objects with
On 4 Jul 2013, at 19:00, Guido van Rossum wrote:
> Thanks for the code pointers. So it's all about monkeypatching. :-) I have
> only a little sympathy, as there still seems to be a way to do this, it's
> just less convenient. Too bad.
>
I've also lamented the death of bound methods in Pytho
On 20 May 2013, at 18:26, Mark Janssen wrote:
>>> I'm hoping that core developers don't get caught-up in the "doctests are bad
>>> meme".
>>>
>>> Instead, we should be clear about their primary purpose which is to test
>>> the examples given in docstrings.
>>> In other words, doctests have a pe
On 7 April 2013 14:44, andrew.svetlov wrote:
> http://hg.python.org/cpython/rev/18fd64f1de2d
> changeset: 83179:18fd64f1de2d
> branch: 3.3
> user:Andrew Svetlov
> date:Sun Apr 07 16:42:24 2013 +0300
> summary:
> Process DEFAULT values in mock side_effect that returns ite
On 19 Mar 2013, at 23:09, "Gregory P. Smith" wrote:
>
> On Tue, Mar 19, 2013 at 9:44 PM, Michael Foord
> wrote:
>>
>> On 19 Mar 2013, at 17:26, Antoine Pitrou wrote:
>>
>> > On Wed, 20 Mar 2013 01:22:58 +0100 (CET)
>> > micha
On 20 Mar 2013, at 01:03, Antoine Pitrou wrote:
> On Wed, 20 Mar 2013 00:50:27 -0700
> Michael Foord wrote:
>>
>> If you want to add support for additional functionality feel free to propose
>> a patch.
>
> This isn't about additional functionality, thi
On 20 Mar 2013, at 00:09, Antoine Pitrou wrote:
> On Tue, 19 Mar 2013 21:44:15 -0700
> Michael Foord wrote:
>>
>> mock_open makes it easy to put a StringIO in place if that's what you want.
>> It's just a simple helper function for providing some known dat
On 19 Mar 2013, at 17:26, Antoine Pitrou wrote:
> On Wed, 20 Mar 2013 01:22:58 +0100 (CET)
> michael.foord wrote:
>> http://hg.python.org/cpython/rev/684b75600fa9
>> changeset: 82811:684b75600fa9
>> user:Michael Foord
>> date:Tue Mar 19
On 5 Mar 2013, at 05:39, Jeff Hardy wrote:
> On Mon, Mar 4, 2013 at 4:39 PM, Michael Foord
> wrote:
>>
>> On 1 Mar 2013, at 18:38, Antoine Pitrou wrote:
>>
>>> On Fri, 1 Mar 2013 09:32:23 -0500
>>> Barry Warsaw wrote:
>>>>
>&
On 5 Mar 2013, at 09:02, Glyph wrote:
> On Mar 4, 2013, at 11:13 PM, Robert Collins wrote:
>
>> In principle maybe. Need to talk with the trial developers, nose
>> developers, py.test developers etc - to get consensus on a number of
>> internal API friction points.
>
> Some of trial's lessons
On 5 Mar 2013, at 07:19, Antoine Pitrou wrote:
> On Mon, 4 Mar 2013 15:47:37 -0800
> Eli Bendersky wrote:
>> On Mon, Mar 4, 2013 at 1:28 PM, Antoine Pitrou wrote:
>>
>>> On Mon, 4 Mar 2013 13:26:57 -0800
>>> Eli Bendersky wrote:
[Splitting into a separate thread]
Do we really
On 4 Mar 2013, at 20:00, Robert Collins wrote:
> On 5 March 2013 05:34, Brett Cannon wrote:
>>
>>
>>
>> On Mon, Mar 4, 2013 at 11:29 AM, Barry Warsaw wrote:
>>>
>>> On Mar 04, 2013, at 07:26 PM, Robert Collins wrote:
>>>
It is of course possible for subunit and related tools to run t
On 4 Mar 2013, at 22:24, Barry Warsaw wrote:
> On Mar 04, 2013, at 05:04 PM, Brett Cannon wrote:
>
>> Sure, but that has nothing to do with programmatic package discovery.
>> That's something you will have to do as a person in making a qualitative
>> decision along the same lines as API design.
On 5 Mar 2013, at 00:23, Robert Collins wrote:
> On 5 March 2013 13:21, Michael Foord wrote:
>>
>
>> We can certainly talk about it - although as Guido says, something specific
>> may be easier to have a useful discussion about.
>>
>> Reading through
On 1 Mar 2013, at 18:38, Antoine Pitrou wrote:
> On Fri, 1 Mar 2013 09:32:23 -0500
> Barry Warsaw wrote:
>>
>>> On the other hand in some ways Jython is sort of like Python on a
>>> weird virtual OS that lets the real OS bleed through some. This may
>>> still need to be checked in that way (th
On 4 Mar 2013, at 20:02, Daniel Holth wrote:
> On Mon, Mar 4, 2013 at 2:26 PM, Berker Peksağ wrote:
>> On Mon, Mar 4, 2013 at 9:14 PM, Barry Warsaw wrote:
>>> On Mar 04, 2013, at 07:41 PM, Antoine Pitrou wrote:
>>>
> $ python -m unittest discover
> $ python setup.py test
> $ pytho
On 28 Feb 2013, at 13:49, Brett Cannon wrote:
>
>
>
> On Thu, Feb 28, 2013 at 6:34 AM, Michael Foord
> wrote:
>
> On 28 Feb 2013, at 07:36, Georg Brandl wrote:
>
> > Am 27.02.2013 17:51, schrieb Michael Foord:
> >> Hello all,
> >>
>
On 4 Mar 2013, at 19:26, Berker Peksağ wrote:
> On Mon, Mar 4, 2013 at 9:14 PM, Barry Warsaw wrote:
>> On Mar 04, 2013, at 07:41 PM, Antoine Pitrou wrote:
>>
$ python -m unittest discover
$ python setup.py test
$ python setup.py nosetests
$ python -m nose test
$ nosete
On 4 Mar 2013, at 06:26, Robert Collins wrote:
> On 4 March 2013 18:54, Guido van Rossum wrote:
>> On Sun, Mar 3, 2013 at 9:24 PM, Robert Collins
>> wrote:
>>> I'd like to talk about overhauling - not tweaking, overhauling - the
>>> standard library testing facilities.
>>
>> That seems like t
On 3 Mar 2013, at 01:29, Trent Nelson wrote:
> On Wed, Feb 27, 2013 at 08:51:16AM -0800, Michael Foord wrote:
>> If you have other items you'd like to discuss please let me know and I
>> can add them to the agenda.
>
>Hmm, seems like this might be a g
On 28 Feb 2013, at 03:42, Barry Warsaw wrote:
> On Feb 27, 2013, at 04:51 PM, Michael Foord wrote:
>
>> If you have other items you'd like to discuss please let me know and I can
>> add them to the agenda.
>
> I'd like to have some discussions around
On 27 Feb 2013, at 19:01, fwierzbi...@gmail.com wrote:
> On Wed, Feb 27, 2013 at 8:51 AM, Michael Foord
> wrote:
>> If you have other items you'd like to discuss please let me know and I can
>> add them to the agenda.
>
> I'd like to discuss merging Jython&#
On 27 Feb 2013, at 18:50, Antoine Pitrou wrote:
> On Wed, 27 Feb 2013 16:51:16 +
> Michael Foord wrote:
>
>> Hello all,
>>
>> PyCon, and the Python Language Summit, is nearly upon us. We have a good
>> number of people confirmed to attend. If
On 28 Feb 2013, at 07:36, Georg Brandl wrote:
> Am 27.02.2013 17:51, schrieb Michael Foord:
>> Hello all,
>>
>> PyCon, and the Python Language Summit, is nearly upon us. We have a good
>> number of people confirmed to attend. If you are intending to come to the
>
I can add
them to the agenda.
All the best,
Michael Foord
--
http://www.voidspace.org.uk/
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing
http://www.sqlite.org/diff
On 27 Feb 2013, at 11:00, David Beazley wrote:
>>
>> From: Eli Bendersky
>>
>> I'll be the first one to admit that pycparser is almost certainly not
>> generally useful enough to be exposed in the stdlib. So just using it as an
>> implementation detail is absolutely fine. PLY is a more intere
Hey folks,
Likely the wrong place to report this, but I couldn't work out the best place
and figured this is only as bad as anywhere else.
A user has reported to webmaster that hgweb is misconfigured (or at least the
server configuration is interfering with hgweb).
The symptom is that this url
There's a problem with the instructions for using Active TCL with Python for
the Mac.
Michael
Begin forwarded message:
> From: "Dr. Anthony G. Francis, Jr."
> Subject: Broken links on
> http://www.python.org/download/mac/tcltk/#activetcl-8-5-11
> Date: 19 December 2012 22:08:02 GMT
> To: web
On 9 Nov 2012, at 09:57, Chris Withers wrote:
> Hi All,
>
> I wanted to run the unit tests before checking in the patch for
> http://bugs.python.org/issue16441, even though it's a trivial change, so I
> was trying to follow the instructions at:
>
> http://docs.python.org/devguide/
>
> I'm o
On 24 Jul 2012, at 11:52, Devin Jeanpierre wrote:
> On Tue, Jul 24, 2012 at 6:07 AM, Michael Foord
> wrote:
>>> This is not an ideal world and 2to3 is not good enough to convert files
>>> without further intervention and testing.
>>
>> It is if you design
On 24 Jul 2012, at 10:30, Terry Reedy wrote:
> On 7/24/2012 12:44 AM, anatoly techtonik wrote:
>
>> Python 3 check explicitly tells the reader that 2to3 should only be
>> used in Python 3. Otherwise everybody need to guess when this *_2to3
>> tools are triggered. As for me, I see no technical li
On 23 Jul 2012, at 19:49, Serhiy Storchaka wrote:
> On 23.07.12 19:38, Jesus Cea wrote:
>> The problem is that if we do ">=", then an unpatched python
>> interpreter could pass the test too. So we are not actually testing
>> the feature.
>>
>> If the repeat counters are going to be optimized, th
On 20 Jul 2012, at 17:50, Maciej Fijalkowski wrote:
> On Fri, Jul 20, 2012 at 2:55 PM, Michael Foord
> wrote:
>
> On 17 Jul 2012, at 23:04, mar...@v.loewis.de wrote:
>
> >> [snip...]
> >
> >> I would like to use a JIT to generate specialized functi
On 17 Jul 2012, at 23:04, mar...@v.loewis.de wrote:
>> [snip...]
>
>> I would like to use a JIT to generate specialized functions for a
>> combinaison of arguments types.
>
> I think history has moved past specializing JITs. Tracing JITs are the
> status quo; they provide specialization as a si
On 6 Jun 2012, at 18:28, Yury Selivanov wrote:
> On 2012-06-06, at 1:13 PM, Alexandre Zani wrote:
>> A question regarding the name. I have often seen the following pattern
>> in decorators:
>>
>> def decor(f):
>> def some_func(a,b):
>> do_stuff using f
>> some_func.__name__ = f.__name_
On 5 Jun 2012, at 08:53, Nick Coghlan wrote:
> [snip...]
>
> Now, one minor annoyance with current class decorators is that they're
> *not* inherited. This is sometimes what you want, but sometimes you
> would prefer to automatically decorate all subclasses as well.
> Currently, that means writi
On 5 Jun 2012, at 09:34, Mark Shannon wrote:
> Steven D'Aprano wrote:
>> On Tue, Jun 05, 2012 at 10:20:58AM +0300, Eli Bendersky wrote:
>>> Still, instance of type()" is a bit too cryptic for mere mortals, IMHO.
>> I think that if somebody finds "instance of type" too cryptic, they won't
>> have
On 4 Jun 2012, at 16:10, Barry Warsaw wrote:
> [snip...]
>>> + However, for a structured record type use
>>> :func:`~collections.namedtuple`
>>>
>>
>> What's with the ~?
>
> I'm not sure, but it seems to result in a cross-reference, and I see tildes
> used elsewhere, so I guess it's some reS
On 4 May 2012, at 09:44, Vinay Sajip wrote:
> IIUC, the program name of the Python executable is set to whatever argv[0] is.
> Is there a reason for this, rather than using one of the various OS-specific
> APIs [1] for getting the name of the running executable? The reason I ask is
> that in a vi
On 2 May 2012, at 18:06, Ezio Melotti wrote:
> On 02/05/2012 19.33, Michael Foord wrote:
>> On 2 May 2012, at 16:55, Terry Reedy wrote:
>>> I would send the above to webmas...@python.org (should be at the bottom of
>>> pages). We develop CPython but do not directly
On 2 May 2012, at 16:55, Terry Reedy wrote:
> On 5/2/2012 10:16 AM, Carl Meyer wrote:
>> Hi all,
>>
>> Are the download pages for older Python versions supposed to be kept up
>> to date at all? I just noticed that the 2.4.6 download page
>> (http://www.python.org/download/releases/2.4.6/) says t
On 31 Mar 2012, at 07:32, Lennart Regebro wrote:
> On Fri, Mar 30, 2012 at 12:38, Serhiy Storchaka wrote:
>> I don't understand why Python may not include the pytz. The Olson tz
>> database is not part of pytz.
>
> Yes it is.
>
>> Python can depend on a system tz database
>
> That works on Un
On 27/03/2012 18:45, Victor Stinner wrote:
[snip...]
Straying from that is only going to create confusion. Besides that, the
one use case for "time.steady()" that you give (benchmarking) is better
served by a clock that follows the C++0x definition.
I added a time.hires() clock to the PEP for t
On 26 Mar 2012, at 08:11, Georg Brandl wrote:
> On 26.03.2012 00:13, michael.foord wrote:
>> http://hg.python.org/cpython/rev/adc1fc2dc872
>> changeset: 75938:adc1fc2dc872
>> user:Michael Foord
>> date:Sun Mar 25 23:12:55 2012 +0100
>>
On 16 Mar 2012, at 11:54, Nick Coghlan wrote:
> On Thu, Mar 15, 2012 at 6:27 AM, Michael Foord
> wrote:
>> On the topic of docs mock documentation is about eight pages long. My
>> intention was to strip this down to just the api documentation, along with a
>> lin
On 17 Mar 2012, at 15:04, Georg Brandl wrote:
> On 03/17/2012 09:47 PM, Michael Foord wrote:
>>
>> On 17 Mar 2012, at 08:49, Georg Brandl wrote:
>>
>>> On 03/15/2012 01:17 AM, victor.stinner wrote:
>>>> http://hg.python.org/cpython/rev/27441e0d6a
On 17 Mar 2012, at 08:49, Georg Brandl wrote:
> On 03/15/2012 01:17 AM, victor.stinner wrote:
>> http://hg.python.org/cpython/rev/27441e0d6a75
>> changeset: 75672:27441e0d6a75
>> user:Victor Stinner
>> date:Thu Mar 15 01:17:09 2012 +0100
>> summary:
>> Issue #10278: Add an opt
On 14 Mar 2012, at 13:46, Terry Reedy wrote:
> On 3/14/2012 4:22 PM, Michael Foord wrote:
>>
>> On 14 Mar 2012, at 13:08, Terry Reedy wrote:
>>
>>> On 3/14/2012 3:25 PM, michael.foord wrote:
>>>> +# mock.py +# Test tools for mocking and patching
On 14 Mar 2012, at 12:33, Georg Brandl wrote:
> On 14.03.2012 20:25, michael.foord wrote:
>> http://hg.python.org/cpython/rev/2fda048ee32a
>> changeset: 75632:2fda048ee32a
>> user:Michael Foord
>> date:Wed Mar 14 12:24:34 2012 -0700
>&
or pointing it out.
I'm maintaining a "clean" (no Python 2 compatibility code) version in the
standard library. I'll be maintaining mock, so I'd like to be assigned any
issues on it and at least talked to before changes are made. I am maintaining a
backport still, but th
On 13 Mar 2012, at 16:57, Victor Stinner wrote:
> Hi,
>
> I added two functions to the time module in Python 3.3: wallclock()
> and monotonic(). I'm unable to explain the difference between these
> two functions, even if I wrote them :-) wallclock() is suppose to be
> more accurate than time() b
thon2 'unicode'
> python3 'bytes' -> python2 '__builtins__.bytes object'
>
It does seem unfortunate that by default it is impossible for a developer to
"do the right thing" as regards pickling / unpickling here. Binary data on
Python 2 being unpickl
s a context manager). Beyond
that the api is stable. A bunch of Python 2 compatibility code can also be
removed in the standard library version.
All the best,
Michael Foord
> Good luck!
>
> --Guido
>
> On Mon, Mar 12, 2012 at 4:01 PM, Gregory P. Smith wrote:
>&g
Hello all,
At the Python Language Summit adding the "mock" library to the Python Standard
Library was discussed and agreed. Here is a very brief PEP covering the
decision and rationale.
All the best,
Michael Foord
PEP: 417
Title: Including mock in the Standard Library
Version:
On 26 Feb 2012, at 17:45, Antoine Pitrou wrote:
>
> Hi,
>
> On Sat, 25 Feb 2012 20:23:39 +
> Armin Ronacher wrote:
>>
>> I just uploaded PEP 414 which proposes am optional 'u' prefix for string
>> literals for Python 3.
>>
>> You can read the PEP online: http://www.python.org/dev/peps/pe
Hey folks,
When we do security only releases of Python we regularly get emails to
webmas...@python.org asking where to find binary builds. If you want to find
the most recent binary builds of Python 2.5 & 2.6, it used to involve clicking
through quite a few links.
I've added links to the lates
On 08/02/2012 15:16, Mark Shannon wrote:
Hi,
Version 2 is now available.
Version 2 makes as few changes to tunable constants as possible, and
generally does not change iteration order (so repr() is unchanged).
All tests pass (the only changes to tests are for sys.getsizeof() ).
Repository: h
e for
instances, which may be overridden by an instance attribute on *some*
instances.
All the best,
Michael Foord
Chris
--
http://www.voidspace.org.uk/
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you giv
On 28/01/2012 04:44, Stephen J. Turnbull wrote:
Michael Foord writes:
> >> Assuming the module is then promoted to the the standard library
proper in
> >> release ``3.X+1``, it will be moved to a permanent location in the
library::
> >>
ard
library is distributed or versioned.
A separate proposal about standard library versioning has been floated
but is *much* more controversial and therefore much less likely to
happen. So I wouldn't hold your breath on it...
All the best,
Michael Foord
___
On 28/01/2012 05:09, Scott Dial wrote:
On 1/27/2012 8:48 PM, Barry Warsaw wrote:
The thinking goes like this: if you would normally use an __preview__ module
because you can't get approval to download some random package from PyPI, well
then your distro probably could or should provide it, so ge
On 27/01/2012 22:54, Barry Warsaw wrote:
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 28/01/2012 13:04, Paul Moore wrote:
On 28 January 2012 09:18, Nick Coghlan wrote:
It's basically us saying to Python users "We're explicitly flagging
this PyPI module for inclusion in the next major Python release. We've
integrated it into our build process, test suite and binary releases,
On 27/01/2012 20:48, Steven D'Aprano wrote:
Eli Bendersky wrote:
try:
from __preview__ import thing
except ImportError:
import thing
So no need to target a very specific version of Python.
Yep, this is what I had in mind. And it appeared too trivial to place
it in the PEP.
Trivial a
view__ adds nothing to the
process.
Sure. __preview__ is for things that *need* previewing.
All the best,
Michael Foord
Even when there are candidates for inclusion with relatively stable
APIs, like regex, we should *assume* that there will be API
differences between __preview__.regex and
On 27/01/2012 15:35, Matt Joiner wrote:
A more normal incantation, as is often the way for packages that became
parts of the standard library after first being a third party library
(sometimes under a different name, e.g. simplejson -> json):
try:
from __preview__ import thing
except Import
On 27/01/2012 15:34, Benjamin Peterson wrote:
2012/1/27 Eli Bendersky:
Criteria for "graduation"
-
I think you also need "Criteria for being placed in __preview__". Do
we just toss everything someone suggests in?
And given that permanently deleting something from __pre
On 27/01/2012 15:09, Antoine Pitrou wrote:
On Fri, 27 Jan 2012 15:21:33 +0200
Eli Bendersky wrote:
Following an earlier discussion on python-ideas [1], we would like to
propose the following PEP for review. Discussion is welcome. The PEP
can also be viewed in HTML form at
http://www.python.org/
On 27/01/2012 14:37, Philippe Fremy wrote:
Hi,
A small comment from a user perspective.
Since a package in preview is strongly linked to a given version of
Python, any program taking advantage of it becomes strongly specific to
a given version of Python.
Such programs will of course break for
On 22 Jan 2012, at 17:43, Łukasz Langa wrote:
> Wiadomość napisana przez Michael Foord w dniu 22 sty 2012, o godz. 14:14:
>
>> ./configure CC=gcc-4.2 --prefix=/dev/null --with-pydebug
>
> Why the phony prefix?
Heh, it's what I've always done - I think copied
to be that way, but it's fine by me as
>> both ways work fine.
>
> I am not sure, that was just try and worked for me, with first option
> suggested by you was throwing same compile error then I tried with this that
> worked :)
The problems compiling Python 3 on th
On 19/01/2012 17:46, Ethan Furman wrote:
Guido van Rossum wrote:
> We should not encourage people to write code that works with a certain
> bugfix release but not with the previous bugfix release of the same
> feature release.
Then what's the point of a bug-fix release? If 3.2.1 had broken
thr
Hello all,
A paper (well, presentation) has been published highlighting security problems
with the hashing algorithm (exploiting collisions) in many programming
languages Python included:
http://events.ccc.de/congress/2011/Fahrplan/attachments/2007_28C3_Effective_DoS_on_web_applicatio
for research projects. They switched to using Python 3 a while ago.
All the best,
Michael Foord
> Mark
>
> On 21/12/2011 6:16 PM, Chris Withers wrote:
>> What's the python-dev view on this?
>>
>> Original Message
>> Subject: Anyone still
still supporting 2.4. The *major* syntax feature you lose
by targeting 2.4 is the with statement, so it will be nice to drop 2.4 support.
The next releases of mock and unittest2 will still support 2.4, but the ones
after that will be 2.5+.
Thankfully tox makes testing across multiple versions
On 13/12/2011 21:10, Terry Reedy wrote:
On 12/13/2011 2:02 PM, PJ Eby wrote:
On Tue, Dec 13, 2011 at 11:24 AM, Antoine Pitrou mailto:solip...@pitrou.net>> wrote:
On Tue, 13 Dec 2011 15:28:31 +0100
"Laurence Rowe" mailto:l...@lrowe.co.uk>> wrote:
>
> The approach that most people seem to
On 13/12/2011 14:28, Laurence Rowe wrote:
On Tue, 13 Dec 2011 14:42:12 +0100, Michael Foord
wrote:
On 13/12/2011 13:33, Laurence Rowe wrote:
On Mon, 12 Dec 2011 22:18:40 +0100, Chris McDonough
wrote:
On Mon, 2011-12-12 at 09:50 -0500, PJ Eby wrote:
As someone who ported WebOb
something else?
Michael
--
Nick Coghlan (via Gmail on Android, so likely to be more terse than usual)
On Dec 13, 2011 11:46 PM, "Michael Foord" <mailto:fuzzy...@voidspace.org.uk>> wrote:
On 13/12/2011 13:33, Laurence Rowe wrote:
On Mon, 12 Dec 2011 22
On 13/12/2011 13:33, Laurence Rowe wrote:
On Mon, 12 Dec 2011 22:18:40 +0100, Chris McDonough
wrote:
On Mon, 2011-12-12 at 09:50 -0500, PJ Eby wrote:
As someone who ported WebOb and other stuff built on top of it
to Python
3 without using "from __future__ import uni
On 9 Dec 2011, at 15:13, Barry Warsaw wrote:
> 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 does
issue it's
not clear to me what needs to be done for it to be accepted (or rejected),
beyond a general "it's a big change".
All the best,
Michael Foord
--
http://www.voidspace.org.uk/
May you do good and not evil
May you find forgiveness for yourself and forgive others
APIs around can require effort just to keep them
working and may actively *prevent* other changes / improvements.
All the best,
Michael Foord
So, I think we should have a clear and working deprecation policy, and
Ezio's suggestion sounds good to me. There should be a clean way to
state, i
On 26/11/2011 07:46, Maciej Fijalkowski wrote:
On Sat, Nov 26, 2011 at 6:39 AM, Nick Coghlan wrote:
On Sat, Nov 26, 2011 at 8:14 AM, Michael Foord
wrote:
On 24 Nov 2011, at 04:06, Nick Coghlan wrote:
On Thu, Nov 24, 2011 at 10:28 AM, Guido van Rossum wrote:
Mea culpa for not keeping
On 24 Nov 2011, at 04:06, Nick Coghlan wrote:
> On Thu, Nov 24, 2011 at 10:28 AM, Guido van Rossum wrote:
>> Mea culpa for not keeping track, but what's the status of PEP 380? I
>> really want this in Python 3.3!
>
> There are two relevant tracker issues (both with me for the moment).
>
> The
On 25/11/2011 15:48, Paul Moore wrote:
On 25 November 2011 15:07, Amaury Forgeot d'Arc wrote:
2011/11/25 Paul Moore
It would be nice to have the optimisation back if it's easy enough to
do so, for quick-and-dirty code, but it is not a good idea to rely on
it (and it's especially unwise to base
On 25/11/2011 00:20, Jesus Cea wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
When mailing there, I get this error. Not sure where to report.
The address works fine. It would be nice if someone fixed the annoying
bounce however. :-)
Michael
"""
Final-Recipient: rfc822; sdr...@sdrees
1 - 100 of 1069 matches
Mail list logo
