On Mon, Nov 6, 2017 at 4:11 AM Nick Coghlan wrote:
> Here's a more-complicated-than-a-doctest-for-a-dict-repo, but still
> fairly straightforward, example regarding the "insertion ordering
> dictionaries are easier to use correctly" argument:
>
> import json
> data = {"a":1, "b":2, "c":3}
On Wed, Nov 22, 2017 at 4:32 PM, Victor Stinner
wrote:
> Aha, contextlib.nullcontext() was just added, cool!
>
So is this equivalent to--
@contextmanager
def yielding(x):
yield x
I thought we were against adding one-line functions?
--Chris
>
> https://github.com/python/cpyt
On Fri, Nov 24, 2017 at 5:06 PM, Nathaniel Smith wrote:
> On Fri, Nov 24, 2017 at 4:22 PM, Guido van Rossum wrote:
>> The more I hear about this topic, the more I think that `await`, `yield` and
>> `yield from` should all be banned from occurring in all comprehensions and
>> generator expressions
I have a couple basic questions around how this API could be used in
practice. Both of my questions are for the Python API as applied to Tasks
in asyncio.
1) Would this API support looking up the value of a context variable for
**another** Task? For example, if you're managing multiple tasks using
On Fri, Jan 5, 2018 at 8:29 AM, Guido van Rossum wrote:
> On Fri, Jan 5, 2018 at 2:05 AM, Victor Stinner
> wrote:
>>
>> Currently, Context.get(var) returns None when "var in context" is false.
>> That's surprising and different than var.get(), especially when var has a
>> default value.
>
> I don
On Mon, Jan 8, 2018 at 11:02 PM, Nathaniel Smith wrote:
> Right now, the set of valid states for a ContextVar are: it can hold
> any Python object, or it can be undefined. However, the only way it
> can be in the "undefined" state is in a new Context where it has never
> had a value; once it leave
On Wed, Jan 10, 2018 at 10:58 PM, Yury Selivanov
wrote:
> On Thu, Jan 11, 2018 at 10:35 AM, Chris Jerdonek
> wrote:
>> On Mon, Jan 8, 2018 at 11:02 PM, Nathaniel Smith wrote:
>>> Right now, the set of valid states for a ContextVar are: it can hold
>>> any Python
On Thu, Jan 18, 2018 at 7:34 AM Christian Heimes
wrote:
> On 2018-01-16 21:17, Christian Heimes wrote:
> We have two options until LibreSSL has addressed the issue:
>
> 1) Make the SSL module more secure, simpler and standard conform
> 2) Support LibreSSL
>
> I started a vote on Twitter [4]. So f
Oh, that makes your original email make much more sense (at least to me). I
also interpreted it to mean you were interested in extending the EOL date
out further, rather than pointing out that it should probably already have
been switched from “bugfix” to “security” status.
—Chris
On Wed, Mar 14,
On Wed, Mar 28, 2018 at 6:15 PM, Nathaniel Smith wrote:
> On Wed, Mar 28, 2018 at 1:03 PM, Serhiy Storchaka wrote:
>> 28.03.18 21:39, Antoine Pitrou пише:
>>> I'd like to submit this PEP for discussion. It is quite specialized
>>> and the main target audience of the proposed changes is
>>> users
On Fri, Mar 30, 2018 at 4:41 AM, Nick Coghlan wrote:
> On 30 March 2018 at 21:16, Nathaniel Smith wrote:
>> And bool(obj) does always return True or False; if you define a
>> __bool__ method that returns something else then bool rejects it and
>> raises TypeError. So bool(bool(obj)) is already in
On Tue, Apr 17, 2018 at 12:46 AM, Chris Angelico wrote:
>
> Having survived four rounds in the boxing ring at python-ideas, PEP
> 572 is now ready to enter the arena of python-dev. I'll let the
> proposal speak for itself. Be aware that the reference implementation
> currently has a few test failu
On Mon, Apr 23, 2018 at 4:54 PM, Greg Ewing wrote:
> Tim Peters wrote:
>
>> if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
>> return g
>
>
> My problem with this is -- how do you read such code out loud?
It could be--
"if diff, which we let equal x - x_base, and g, which ..." or
"if di
On Thu, Apr 26, 2018 at 12:25 PM, Serhiy Storchaka wrote:
> f(b=2, *[1]) is surprised in two ways:
>
> 1. Argument values are passed not in order. The first value is assigned to
> the second parameter, and the second value is assigned to the first
> parameter.
>
> 2. Argument values are evaluated
On Thu, Apr 26, 2018 at 10:33 AM, Sven R. Kunze wrote:
> On 25.04.2018 01:19, Steven D'Aprano wrote:
>>
>> Sorry, gcd(diff, n) is not the "perfect name", and I will tell you that
>> sometimes g is better. [...]
>
> We were talking about the real-world code snippet of Tim (as a justification
> of :
On Tue, May 1, 2018 at 2:14 AM, Steve Holden wrote:
> On Tue, May 1, 2018 at 3:36 AM, Chris Jerdonek
> wrote:
>>
>> On Thu, Apr 26, 2018 at 10:33 AM, Sven R. Kunze wrote:
>> > On 25.04.2018 01:19, Steven D'Aprano wrote:
>> >>
>> >> Sorry,
FYI, a lot of these ideas were discussed back in September and October of
2017 on this list if you search the subject lines for "startup" e.g.
starting here and here:
https://mail.python.org/pipermail/python-dev/2017-September/149150.html
https://mail.python.org/pipermail/python-dev/2017-October/14
What does “no release at all” mean? If it’s not released, how would people
use it?
—Chris
On Tue, May 15, 2018 at 9:36 PM Alex Walters
wrote:
> In the spirit of learning why there is a fence across the road before I
> tear
> it down out of ignorance [1], I'd like to know the rationale behind so
On Tue, Jun 5, 2018 at 7:03 PM Ivan Pozdeev via Python-Dev <
[email protected]> wrote:
> On 05.06.2018 17:28, Martin Gainty wrote:
>
> who owns the Data hosted on Github?
>
> Github Author?
> Microsoft?
>
>
> Martin
>
>
> https://help.github.com/articles/github-terms-of-service/#d-user-generat
On Tue, Oct 13, 2015 at 8:26 AM, Random832 wrote:
> "R. David Murray" writes:
>
>> On Tue, 13 Oct 2015 14:59:56 +0300, Stefan Mihaila
>> wrote:
>>> Maybe it's just python2 habits, but I assume I'm not the only one
>>> carelessly thinking that "iterating over an input a second time will
>>> resul
On Tue, Dec 22, 2015 at 4:35 PM, Benjamin Peterson wrote:
> We've played around with robots.txt, but it's still useful for old docs
> to be indexed (e.g., for removed features), which just need to figure
> out how to get them deprecation in results. I wonder if ref="canonical"> in the old docs wo
On Fri, May 27, 2016 at 9:26 PM, Guido van Rossum wrote:
> We discussed this over dinner at PyCon, some ideas we came up with:
>
> - Dependent types, harking back to a similar concept in Ada
> (https://en.wikibooks.org/wiki/Ada_Programming/Type_System#Derived_types)
> which in that language is als
(status := "Accepted") and "Congratulations!" ;-) (hope I did that right,
but I can't try it yet!)
Thanks for hanging in there, Guido, and for your patience with everyone
during the discussions. I'm glad you're still with us!
--Chris
On Wed, Jul 11, 2018 at 5:10 PM, Guido van Rossum wrote:
>
On Wed, Jul 25, 2018 at 8:07 AM, Tim Golden wrote:
> One problem is that certain tests use support.TESTFN (a local directory
> constructed from the pid) for output files etc. However this can cause
> issues on Windows when recreating the folders / files for multiple tests,
> especially when runnin
On Fri, Jul 27, 2018 at 6:41 AM, Giampaolo Rodola' wrote:
>
> Being TESTFN a global name it appears not suited for parallel testing.
It was designed for parallel testing though:
# Disambiguate TESTFN for parallel testing, while letting it remain a valid
# module name.
TESTFN = "{}_{}_tmp".format
On Sat, Jul 28, 2018 at 10:20 AM, Tim Golden wrote:
>
> Here's the thing. The TESTFN approach creates a directory per process
> test_python_ and some variant of @test__tmp inside that directory.
I filed an issue some years back about this (still open):
https://bugs.python.org/issue15305
The pid i
On Thu, Jul 26, 2018 at 2:05 PM, Tim Golden wrote:
> https://github.com/python/cpython/commit/6a62e1d365934de82ff7c634981b3fbf218b4d5f
> commit: 6a62e1d365934de82ff7c634981b3fbf218b4d5f
> branch: master
> author: Tim Golden
> committer: GitHub
> date: 2018-07-26T22:05:00+01:00
> summary:
>
> bpo
On Sat, Jul 28, 2018 at 5:40 PM Brett Cannon wrote:
>
> On Sat, Jul 28, 2018, 15:13 eryk sun, wrote:
>
>> On Sat, Jul 28, 2018 at 9:17 PM, Jeremy Kloth
>> wrote:
>> >
>> > *PLEASE*, don't use tempfile to create files/directories in tests. It
>> > is unfriendly to (Windows) buildbots. The curr
On Mon, Jul 30, 2018 at 8:46 AM, Tim Golden wrote:
> On 30/07/2018 16:41, Nick Coghlan wrote:
>>
>> On 29 July 2018 at 03:20, Tim Golden wrote:
>>>
>>> I think that was my starting point: rather than develop increasingly
>>> involved and still somewhat brittle mechanisms, why not do what you'd
>>
FWIW, it looks like this is the first (earliest) merge commit that
caused the v2.7.4 line to contain
cf86e368ebd17e10f68306ebad314eea31daaa1e:
$ git show -q d26b658f1433a28b611906c078f47bc804a63dd1
commit d26b658f1433a28b611906c078f47bc804a63dd1
Merge: 2d639d5665 f8b9dfd9a1
Author:
Another one is GitHub (and the bug tracker, for that matter). For
example, I believe here is where the discussion took place that led to
the initial draft of PEP 582 re: recognizing a local __packages__
directory:
https://github.com/kushaldas/peps/pull/1
The PEP was posted here:
https://github.com
On Tue, Oct 9, 2018 at 7:13 PM Benjamin Peterson wrote:
> On Tue, Oct 9, 2018, at 17:14, Barry Warsaw wrote:
> > On Oct 9, 2018, at 16:21, Steven D'Aprano wrote:
> > >
> > > On Tue, Oct 09, 2018 at 10:26:50AM -0700, Guido van Rossum wrote:
> > >> My feeling is that limiting it to strings is fine,
On Tue, Oct 9, 2018 at 8:55 PM Guido van Rossum wrote:
> On Tue, Oct 9, 2018 at 7:49 PM Chris Jerdonek
> wrote:
>> On Tue, Oct 9, 2018 at 7:13 PM Benjamin Peterson wrote:
>> > Can anyone think of a situation where it would be advantageous for an
>> > implement
On Thu, Oct 18, 2018 at 9:11 AM Michael Selik wrote:
> On Thu, Oct 18, 2018 at 8:35 AM Sean Harrington wrote:
>> Further, let me pivot on my idea of __qualname__...we can use the `id` of
>> `func` as the cache key to address your concern, and store this `id` on the
>> `task` tuple (i.e. an inte
A simpler feature that could possibly help him (assuming there isn't any
external state to deal with) would be the ability to save everything at a
certain point in time, and then resume it later. He could rig things up to
save the state e.g. after every hour: 1 hour, 2 hours, etc. Then if an
error
copy of the second one and pause it for a few minutes before
restarting, in case the second one also errors out, and so on. This would
be more useful only in the case of deterministic errors.
--Chris
On Mon, Oct 29, 2018 at 11:59 AM Chris Jerdonek
wrote:
> A simpler feature that could possi
Just to close (or continue) the loop on this thread, I just nominated
David for the steering council:
https://discuss.python.org/t/steering-council-nomination-david-mertz/647
Thanks for stepping forward with your interest and willingness to serve, David!
--Chris
On Fri, Jan 4, 2019 at 12:37 PM A
Hi Serhiy,
That's terrible and sounds frightening. Were you able to get medical
care to get a diagnosis and treatment if needed?
We all hope your condition improves.
--Chris
On Sat, Jan 19, 2019 at 2:14 AM Serhiy Storchaka wrote:
>
> I have virtually completely lost the sight of my right eye (
On Mon, Oct 19, 2020 at 3:11 PM Thomas Wouters wrote:
> PEP: 640
> Title: Unused variable syntax
> Author: Thomas Wouters
>
...
> In Python it is somewhat common to need to do an assignment without
> actually
> needing the result. Conventionally, people use either ``"_"`` or a name
> such
> as
I don't know if this is already covered in the discussion and in our
processes, but in addition to documenting the instructions in the release
in which things break, I think it would also be good to include such
instructions in any earlier release in which the thing is merely
deprecated. In those c
On Mon, Jan 25, 2021 at 7:51 AM Ivan Pozdeev via Python-Dev <
[email protected]> wrote:
> Just _names_? There's a recurring error case when a 3rd-party module
> overrides a standard one if it happens to have the same name. If you
> filter such a module out, you're shooting yourself in the foot
On Mon, Jan 25, 2021 at 2:05 PM Victor Stinner wrote:
> On Mon, Jan 25, 2021 at 6:37 PM Chris Jerdonek
> wrote:
> > On Mon, Jan 25, 2021 at 7:51 AM Ivan Pozdeev via Python-Dev <
> [email protected]> wrote:
> >>
> >> Just _names_? There's a
On Mon, Jan 25, 2021 at 10:23 PM Random832 wrote:
> On Mon, Jan 25, 2021, at 18:44, Chris Jerdonek wrote:
> > But to issue a warning when a standard module is being overridden like
> > I was suggesting, wouldn’t you also need to know whether the name of
> > the modul
On Mon, Apr 5, 2021 at 3:07 AM Nathaniel Smith wrote:
> - Recording pre-empted exceptions: This is another type of metadata that
> would be useful to print along with the traceback. It's non-obvious and a
> bit hard to explain, but multiple trio users have complained about this, so
> I assume it
On Fri, May 7, 2021 at 5:44 PM Pablo Galindo Salgado
wrote:
> Some update on the numbers. We have made some draft implementation to
> corroborate the
> numbers with some more realistic tests and seems that our original
> calculations were wrong.
> The actual increase in size is quite bigger than
On Fri, May 7, 2021 at 6:39 PM Steven D'Aprano wrote:
> On Fri, May 07, 2021 at 06:02:51PM -0700, Chris Jerdonek wrote:
>
> > To know what compression methods might be effective, I’m wondering if it
> > could be useful to see separate histograms of, say, the start column
On Wed, May 12, 2021 at 10:48 AM Mark Shannon wrote:
> ...
> For those of you aware of the recent releases of Cinder and Pyston,
> PEP 659 might look similar.
> It is similar, but I believe PEP 659 offers better interpreter
> performance and is more suitable to a collaborative, open-source
> deve
On Thu, May 27, 2021 at 8:30 PM Ethan Furman wrote:
> But what if we have something like:
>
> class Color(Flag):
> RED = 1# 0001
> BLUE = 4 # 0100
> WHITE = 7 # 0111
>
> As you see, WHITE is an "alias" for a value that does not exist
On Wed, Jun 2, 2021 at 8:04 PM Ethan Furman wrote:
>
> Thank you everyone for your ideas! Instead of adding another
> single-purpose decorator, I'm toying with the idea of
> adding a general purpose decorator that accepts instructions. Something
> along the lines of:
> ...
> Thoughts?
>
I had
On Fri, Oct 8, 2021 at 8:11 AM Guido van Rossum wrote:
> To be clear, Sam’s basic approach is a bit slower for single-threaded
> code, and he admits that.
>
Is it also slower even when running with PYTHONGIL=1? If it could be made
the same speed for single-threaded code when running in GIL-enabl
On Tue, Feb 19, 2013 at 2:28 AM, Nick Coghlan wrote:
> On Tue, Feb 19, 2013 at 7:37 PM, M.-A. Lemburg wrote:
>> On 17.02.2013 11:11, Nick Coghlan wrote:
>> I'm not against modernizing the format, but given that version 1.2
>> has been out for around 8 years now, without much following,
>> I think
On Tue, Feb 19, 2013 at 3:16 PM, Daniel Holth wrote:
> Sorry, Chris must have meant http://hg.python.org/distlib/ . I was
> struggling to imagine a world where that is more visible than something on
> bitbucket.
I meant that bringing distlib into http://hg.python.org/cpython/ would
give it more v
> On Wednesday, February 20, 2013 at 2:48 AM, Chris Jerdonek wrote:
>
> I meant that bringing distlib into http://hg.python.org/cpython/ would
> give it more visibility to core devs and others that already keep an
> eye on python-checkins (the mailing list). And I think seei
On Thu, Feb 28, 2013 at 1:30 AM, Antoine Pitrou wrote:
> Le Wed, 27 Feb 2013 11:33:30 -0800,
> "[email protected]" a écrit :
>>
>> There are a couple of spots that might be more controversial. For
>> example, Jython has a file Lib/zlib.py that implements zlib in terms
>> of the existing Java
On Fri, Jun 10, 2016 at 11:29 AM, David Mertz wrote:
> This is fairly academic, since I do not anticipate needing to do this
> myself, but I have a specific question. I'll assume that Python 3.5.2 will
> go back to the 2.6-3.4 behavior in which os.urandom() never blocks on Linux.
> Moreover, I un
On Mon, Jun 20, 2016 at 12:24 PM, Ethan Furman wrote:
>
> has been created:
>
> https://mail.python.org/mailman/listinfo/security-sig
>
> The purpose of this list is to discuss security-related enhancements to
> Python while having as little impact on backwards compatibility as possible.
I wou
$PYTHONHOME to [:]
>
> On Aug 8, 2016, at 03:25, Chris Jerdonek wrote:
>> FWIW, I would be interested in learning more about the above warning
>> (its significance, how it can be addressed, whether it can be ignored,
>> etc). I also get this message when installing 3.5.2 f
Great work, Victor! It seems like this would be an easy thing to
mention at the beginning of conference talks and meetup presentations,
and also something to ask coworkers if you work at a company that uses
Python (e.g. on workplace Slack channels, etc).
--Chris
On Tue, Jul 4, 2017 at 6:15 AM,
On Thu, Jul 20, 2017 at 8:49 PM, Nick Coghlan wrote:
> ...
> * Lazy loading can have a significant impact on startup time, as it
> means you don't have to pay for the cost of finding and loading
> modules that you don't actually end up using on that particular run
>
> We've historically resisted a
On Fri, Jul 21, 2017 at 9:52 AM, Brett Cannon wrote:
> On Thu, 20 Jul 2017 at 22:11 Chris Jerdonek
> wrote:
>> On Thu, Jul 20, 2017 at 8:49 PM, Nick Coghlan wrote:
>> > ...
>> > * Lazy loading can have a significant impact on startup time, as it
>> > mean
/bugs.python.org/issue9548
collections.abc: http://bugs.python.org/issue19218
--Chris
>
> Victor
>
> Le 22 juil. 2017 07:20, "Chris Jerdonek" a écrit
> :
>>
>> On Fri, Jul 21, 2017 at 9:52 AM, Brett Cannon wrote:
>> > On Thu, 20 Jul 2017 at 22:11
Hi Jim, it seems like each time you reply you change the subject line and
start a new thread. Very few others are doing this (e.g. Yury when
releasing a new version). Would it be possible for you to preserve the
threading like others?
--Chris
On Sun, Aug 27, 2017 at 9:08 AM Jim J. Jewett wrote:
https://github.com/python/cpython/commit/bd73e72b4a9f019be514954b1d40e64dc3a5e81c
> commit: bd73e72b4a9f019be514954b1d40e64dc3a5e81c
> branch: master
> author: Allen W. Smith, Ph.D
> committer: Antoine Pitrou
> date: 2017-08-30T00:52:18+02:00
> summary:
>
> ...
> @@ -307,6 +309,10 @@ def imap(sel
> https://github.com/python/cpython/commit/bd73e72b4a9f019be514954b1d40e64dc3a5e81c
> commit: bd73e72b4a9f019be514954b1d40e64dc3a5e81c
> branch: master
> author: Allen W. Smith, Ph.D
> committer: Antoine Pitrou
> date: 2017-08-30T00:52:18+02:00
> summary:
>
> bpo-5001: More-informative multiproce
On Tue, Nov 2, 2021 at 7:21 AM Petr Viktorin wrote:
> That brings us to possible changes in Python in this area, which is an
> interesting topic.
Is there a use case or need for allowing the comment-starting character “#”
to occur when text is still in the right-to-left direction? Disallowing
Have you also considered changes to the modules under test that might make
it easier for both implementations to exist and be tested side-by-side (so
with fewer hacks on the testing side)?
—Chris
On Wed, May 6, 2020 at 2:33 PM Paul Ganssle wrote:
> Thanks for the suggestion.
>
> I think I tried
To expand on my earlier comment about changing the module under test to
make your testing easier, asyncio is one library that has lots of tests of
different combinations of its C and Python implementations being used
together.
As far as I know, it doesn't use import_fresh_module or similar hackery
Here’s another advantage of having a separate function that I didn’t see
acknowledged in the PEP:
If strict behavior is a better default for a zip-like function than
non-strict, then choosing a new function would let you realize that better
default. In contrast, by adding a new argument to the exi
On Wed, Jun 3, 2020 at 6:09 AM Mark Shannon wrote:
> Also, can we remove all the new API functions added in 3.9 before the
> release and it is too late?
>
I think it would be helpful to open an issue that lists the 40 new
functions, so people could more easily review them before 3.9 is released.
On Sun, Jun 14, 2020 at 9:19 AM Serhiy Storchaka
wrote:
> It is possible to create a loop by setting the __context__ attribute of
> the raised exception, either explicitly, or implicitly, using "raise ...
> from ...".
I think we should separate the questions of what to do when (1) setting the
c
On Tue, Jun 23, 2020 at 9:12 AM Guido van Rossum wrote:
> I'm happy to present a new PEP for the python-dev community to review.
> This is joint work with Brandt Bucher, Tobias Kohn, Ivan Levkivskyi and
> Talin.
>
...
>
I'll mostly let the PEP speak for itself:
> - Published: https://www.python.o
On Thu, Jun 25, 2020 at 11:52 AM Brett Cannon wrote:
> On Thu, Jun 25, 2020 at 5:45 AM Antoine Pitrou
> wrote:
>
>> I don't think this really works. A PEP has to present a consistent
>> view of the world, and works as a cohesive whole. Arguments against a
>> PEP don't form a PEP in themselves,
On Wed, Jun 24, 2020 at 5:15 PM Yonatan Zunger via Python-Dev <
[email protected]> wrote:
> That said, the meta-question still applies: Are there things which are
> generally intended *not* to be interruptible by signals, and if so, is
> there some consistent way of indicating this?
>
Yonatan
On Sat, Jul 25, 2020 at 12:17 PM Jim J. Jewett wrote:
> I certainly understand saying "this change isn't important enough to
> justify a change."
>
> But it sounds as though you are saying the benefit is irrelevant;
Jim, if you include what you’re replying to in your own message (like I’m
doing
MOn Wed, Oct 14, 2020 at 8:03 AM Pablo Galindo Salgado
wrote:
> > Would it be possible rerun the tests with the current
> setup for say the last 1000 revisions or perhaps a subset of these
> (e.g. every 10th revision) to try to binary search for the revision which
> introduced the change ?
>
> Ev
Hi folks,
I have a patch to the unittest module for review here:
http://bugs.python.org/issue7559#msg102801
(There have already been a couple rounds of discussion on how to best
fix this.)
This is my first patch, so any feedback is appreciated.
Thanks,
--Chris
_
Here is another patch for review:
http://bugs.python.org/issue8370
This is a trivial fix to the 2.6 and 2.7 documentation.
Thanks,
--Chris
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Wed, Apr 14, 2010 at 2:07 AM, Michael Foord
wrote:
> I'm still not convinced that this isn't a backwards incompatible change - up
> until now, however horrible it may be, TestLoader.loadTestsFromName only
> raised an AttributeError when it failed to load a test. Changing it to allow
> it propag
On Wed, Apr 14, 2010 at 4:12 AM, Michael Foord
wrote:
> On 14/04/2010 12:54, Chris Jerdonek wrote:
>>
>> On Wed, Apr 14, 2010 at 2:07 AM, Michael Foord
>> wrote:
>>
>>>
>>> I'm still not convinced that this isn't a backwards incompatible ch
On Wed, Apr 14, 2010 at 1:32 PM, Brett Cannon wrote:
> There is no need to email python-dev about individual patches just to get
> them looked at. There is a mailing list that we all subscribe to that send
> an email on all new issues and another one on every change to any issue. You
> should only
I was wondering if someone could review the following minor
documentation patches:
Document that filecmp.dircmp comparisons are "shallow" (7/5/2012):
http://bugs.python.org/issue15250
Document dircmp.left and dircmp.right (7/6/2012):
http://bugs.python.org/issue15269
Update "PyPI package display
> Date: Mon, 23 Jul 2012 19:17:32 +0200
> From: Antoine Pitrou
> To: [email protected]
> Subject: [Python-Dev] Doc/ACKS and Misc/ACKS
>
>> > Doc/ACKS.txt is *only* for acknowledging documentation
>> > contributions. Serhiy is already in Misc/ACKS. No need to add him
>> > to Doc/ACKS.txt.
>>
>
I have a few questions about feature freeze:
(1) Is increasing test coverage acceptable during feature freeze, even
if it does not involve fixing a bug?
(2) When adding new tests (e.g. in the course of fixing a bug or
increasing test coverage), are we allowed to refactor other tests so
that suppo
On Sat Jul 28 10:54:24 CEST 2012, Serhiy Storchaka storchaka at gmail.com wrote:
> For not to duplicate the supporting code, I suggest
> add (move from test_sys test) three utility functions to test.support
> module (issue #15467). Also from the use of the common code will benefit
> issues #15402
On Wed, Jul 25, 2012 at 4:29 PM, Benjamin Peterson wrote:
>> (2) When adding new tests (e.g. in the course of fixing a bug or
>> increasing test coverage), are we allowed to refactor other tests so
>> that supporting test code can be shared? Or should the tests be added
>> in a less DRY fashion a
On Sat, Jul 28, 2012 at 6:21 AM, Nick Coghlan wrote:
> On Sat, Jul 28, 2012 at 8:25 PM, Chris Jerdonek
> wrote:
>> Also, this response seems somewhat at odds to the response I got to a
>> patch that refactors part of regrest, fixes some bugs in it, and adds
>> its first u
On Thu, Aug 2, 2012 at 7:32 AM, Barry Warsaw wrote:
> On Aug 02, 2012, at 03:04 PM, nick.coghlan wrote:
>
>>-module. Specifically, any module that contains an ``__path__`` attribute is
>>+module. Specifically, any module that contains a ``__path__`` attribute is
>
> I find this change hilarious!
I would like people's opinions on issue 15510, specifically whether it
should be addressed and in what versions:
http://bugs.python.org/issue15510
Jesús suggested that I ask. The issue relates to textwrap.wrap()'s
behavior when wrapping strings that contain no non-whitespace
characters -- in par
On Fri, Aug 3, 2012 at 3:59 PM, antoine.pitrou
wrote:
> http://hg.python.org/cpython/rev/f17a1410ebe5
> changeset: 78401:f17a1410ebe5
> summary:
> Make TextIOWrapper's documentation clearer by copying the newline
> argument's description from open().
Now that this change is made, it may make
On Sun, Aug 5, 2012 at 1:48 AM, nick.coghlan wrote:
> http://hg.python.org/devguide/rev/f518f23d06d5
> changeset: 539:f518f23d06d5
> summary:
> It has been pointed out this paragraph was incorrect. One of the Windows
> devs will need to fill in more accurate info
> diff --git a/setup.rst b/se
On Sat, Aug 4, 2012 at 11:51 AM, Victor Stinner
wrote:
> 2012/8/4 Chris Jerdonek :
>> Now that this change is made, it may make sense to update the
>> subprocess documentation to reference TextIOWrapper's documentation
>> instead of open()'s (since use of the '
On Fri, Aug 10, 2012 at 9:21 AM, brett.cannon
wrote:
> http://hg.python.org/cpython/rev/0a75ce232f56
> changeset: 78485:0a75ce232f56
> user:Brett Cannon
> date:Fri Aug 10 12:21:12 2012 -0400
> summary:
> Issue #15502: Finish bringing importlib.abc in line with the current
> +
On Sat, Aug 11, 2012 at 9:40 AM, Georg Brandl wrote:
> On 08/11/2012 04:49 PM, R. David Murray wrote:
>> On Fri, 10 Aug 2012 16:56:43 -0700, Chris Jerdonek
>> wrote:
>>> On Fri, Aug 10, 2012 at 9:21 AM, brett.cannon
>>> wrote:
>>> > http://hg.python
On Sun, Aug 12, 2012 at 1:25 AM, sandro.tosi wrote:
> http://hg.python.org/cpython/rev/233673503217
> changeset: 78512:233673503217
> user:Sandro Tosi
> date:Sun Aug 12 10:24:50 2012 +0200
> summary:
> zip() returns an iterator, make a list() of it; thanks to Martin from docs@
On Sun, Aug 12, 2012 at 6:37 AM, Nick Coghlan wrote:
> On Sun, Aug 12, 2012 at 11:00 PM, Andrew Svetlov
> wrote:
>> I doubt if we will convert all docs to pass doctests, at least quickly.
>> Also making docs doctest-safe sometimes requires less clean and worse
>> readable notation.
>
> About the
Now that the 3.3 release clone has been created, can someone clarify
what changes are allowed to go into the default branch? Is it the
same policy as if the changes were going into the release clone
directly (i.e. code freeze unless you have Georg's approval), or are
future changes for 3.3.1 okay,
Is there a list somewhere of the IRC nicks of the core developers that
use IRC (and who wish to be listed) alongside their real names? If
there is no such list, has there ever been discussion on python-dev of
creating such a list?
--Chris
___
Python-Dev
On Thu, Aug 30, 2012 at 12:57 PM, Terry Reedy wrote:
> If one goes to http://hg.python.org/cpython/ and clicks 'browse', it
> defaults to 2.7, not to default (now 3.3). Moreover, there is no indication
> that it is defaulting to an old branch rather than current default, as one
> might reasonably
On Tue, Sep 4, 2012 at 2:24 AM, Andrew Svetlov wrote:
> Unittests for subprocess module has weird comment:
> We cannot use os.path.realpath to canonicalize the path, since it
> doesn't expand Tru64 {memb} strings.
> See bug 1063571.
> http://hg.python.org/cpython/file/82ae284cd5f1/Lib/test/test_su
On Tue, Sep 4, 2012 at 5:02 AM, Victor Stinner wrote:
>> Or maybe we can drop support for Tru64 as well as we already does it
>> for, say, VMS?
>
> See the PEP 11 for unsupported platforms.
> http://www.python.org/dev/peps/pep-0011/#no-longer-supported-platforms
>
> "Name: VMS
> Unsupported in: Py
1 - 100 of 160 matches
Mail list logo