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
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 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 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, 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 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 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 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 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, 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 <
> python-dev@python.org> wrote:
> >>
> >> Just _names_? There's a
On Mon, Jan 25, 2021 at 7:51 AM Ivan Pozdeev via Python-Dev <
python-dev@python.org> 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
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, 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
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
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
On Wed, Jun 24, 2020 at 5:15 PM Yonatan Zunger via Python-Dev <
python-dev@python.org> 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 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 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 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 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.
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
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
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
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 (
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
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
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
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
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 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,
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
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:
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
>>
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 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 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 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 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
(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 Tue, Jun 5, 2018 at 7:03 PM Ivan Pozdeev via Python-Dev <
python-dev@python.org> 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
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
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
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,
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 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 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 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 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 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
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 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
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 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 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
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, 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
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 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}
> 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
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
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:
/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
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
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
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,
$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
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
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 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
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 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 Thu, Feb 28, 2013 at 1:30 AM, Antoine Pitrou wrote:
> Le Wed, 27 Feb 2013 11:33:30 -0800,
> "fwierzbi...@gmail.com" 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 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 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 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 Sun, Feb 3, 2013 at 11:40 AM, Chris Jerdonek
wrote:
> On Sun, Feb 3, 2013 at 10:33 AM, Éric Araujo wrote:
>> Le 03/02/2013 07:48, Antoine Pitrou a écrit :
>>> I vote for removing the "distutils is frozen" principle.
>> I’ve also been thinking about that.
On Sun, Feb 3, 2013 at 10:33 AM, Éric Araujo wrote:
> Le 03/02/2013 07:48, Antoine Pitrou a écrit :
>> I vote for removing the "distutils is frozen" principle.
> I’ve also been thinking about that. There have been two exceptions to
> the freeze, for ABI flags in extension module names and for pyc
On Wed, Jan 23, 2013 at 6:16 PM, Ezio Melotti wrote:
> On Wed, Jan 23, 2013 at 9:43 PM, Antoine Pitrou wrote:
>> On Wed, 23 Jan 2013 20:41:11 +0100
>> "Amaury Forgeot d'Arc" wrote:
>>> 2013/1/22 Antoine Pitrou
>>>
>>> > I've upgraded the Mercurial version on hg.python.org. If there any
>>> > pr
On Sun, Jan 13, 2013 at 2:40 AM, Charles-François Natali
wrote:
> Hello,
>
>> PEP: 433
>> Title: Add cloexec argument to functions creating file descriptors
>
> I'm not a native English speaker, but it seems to me that the correct
> wording should be "parameter" (part of the function
> definition/
On Thu, Jan 10, 2013 at 11:35 PM, Cron Daemon wrote:
> /home/docs/devguide/documenting.rst:766: WARNING: term not in glossary:
> bytecode
FYI, this warning is spurious (second time at least). I made an issue
about it here:
http://bugs.python.org/issue16928
--Chris
On Thu, Jan 3, 2013 at 1:06 PM, Glenn Linderman wrote:
> Jesus' suggestion of a hidden version field would help, but could be
> annoying for the case of someone writing a lengthy response, and having it
> discarded because the hidden version field is too old... so care would have
> to be taken to
On Sat, Dec 29, 2012 at 12:05 PM, Cron Daemon wrote:
> /home/docs/devguide/documenting.rst:768: WARNING: term not in glossary:
> bytecode
Why is this warning reported? I can't reproduce on my system, and on
my system and in the published online docs, the term successfully
links to:
http://docs
On Thu, Dec 27, 2012 at 12:05 PM, serhiy.storchaka
wrote:
> http://hg.python.org/cpython/rev/26eb2979465c
> changeset: 81094:26eb2979465c
> branch: 2.7
> parent: 81086:ccbb16719540
> parent: 81090:d3c81ef728ae
> user:Serhiy Storchaka
> date:Thu Dec 27 22:00:12 201
On Sun, Dec 23, 2012 at 6:19 PM, Terry Reedy wrote:
> On 12/23/2012 4:47 PM, Chris Jerdonek wrote:
>> On Sun, Dec 23, 2012 at 12:03 PM, Terry Reedy wrote:
>>>
>>>> +# For example, PyPy 1.9.0 raised TypeError for these cases because
>>>> it
>&
On Sun, Dec 23, 2012 at 12:03 PM, Terry Reedy wrote:
>
>> +# For example, PyPy 1.9.0 raised TypeError for these cases because it
>> +# expects x to be a string if base is given.
>> +@support.cpython_only
>> +def test_base_arg_with_no_x_arg(self):
>> +self.assertEquals(int(b
On Sat, Dec 22, 2012 at 6:58 AM, Nick Coghlan wrote:
> On Sun, Dec 23, 2012 at 12:14 AM, Stefan Krah wrote:
>> Hi,
>>
>> hg.python.org seems to be unreachable (tested from various IP addresses).
>
> The docs build daemon started complaining on python-checkins about
> 2:10 pm UTC (on the 22nd), so
On Fri, Dec 21, 2012 at 6:46 AM, Brett Cannon wrote:
>
> On Thu, Dec 20, 2012 at 7:35 PM, Chris Jerdonek
> wrote:
>>
>> I don't disagree that he shouldn't have cross-posted. I was just
>> pointing out that the language should be clarified. What's
On Thu, Dec 20, 2012 at 1:12 PM, Brett Cannon wrote:
>
> On Thu, Dec 20, 2012 at 3:55 PM, Chris Jerdonek
> wrote:
>>
>> On Thu, Dec 20, 2012 at 12:18 PM, Brett Cannon wrote:
>> >
>> > And please do not CC the peps mailing list on discussions. It should
>
On Thu, Dec 20, 2012 at 12:18 PM, Brett Cannon wrote:
>
> And please do not CC the peps mailing list on discussions. It should only be
> used to mail in new PEPs or acceptable patches to PEPs.
PEP 1 should perhaps be clarified if the above is the case.
Currently, PEP 1 says all PEP-related e-mail
On Thu, Dec 13, 2012 at 6:48 PM, R. David Murray wrote:
> On Thu, 13 Dec 2012 20:21:24 -0500, Trent Nelson wrote:
>> - Use a completely separate clone to house all the intermediate
>> commits, then generate a diff once the final commit is ready,
>> then apply that diff
On Dec 10, 2012, at 1:52 PM, Terry Reedy wrote:
> My question, Guido, is how this will affect Python development, and in
> particular, your work on async. If not proprietary info, does or will Dropbox
> use Python3?
I talked to some Dropbox people tonight, and they said they use 2.7
for the cl
On Sun, Dec 9, 2012 at 3:30 PM, anatoly techtonik wrote:
> Just to let you know that annotate in hgweb is broken for Python sources.
>
> http://hg.python.org/cpython/annotate/692be1f9fa1d/Lib/distutils/tests/test_register.py
Maybe I'm missing something, but what's broken about it? Also, in my
ex
I would like to know when we should use "class" in the Python 3
documentation, and when we should use "type." Are these terms
synonymous in Python 3, and do we have a preference for which to use
and when?
I'm sure this has been discussed before. But if this terminology
issue has already been res
On Wed, Nov 21, 2012 at 6:07 PM, chris.jerdonek
wrote:
> http://hg.python.org/devguide/rev/78a69b929ab7
> changeset: 573:78a69b929ab7
> user: Chris Jerdonek
> date:Wed Nov 21 18:04:35 2012 -0800
> summary:
> Add instructions for handling merge conflicts
On Sat, Nov 17, 2012 at 10:55 AM, Chris Angelico wrote:
> On Sun, Nov 18, 2012 at 5:47 AM, Chris Jerdonek
> wrote:
>> On Thu, Oct 4, 2012 at 2:46 PM, wrote:
>>> I really fail to see what problem people have with large source files.
>>> What is it that you want to
[Apologies for resurrecting a few-weeks old thread.]
On Thu, Oct 4, 2012 at 2:46 PM, wrote:
>
> Zitat von Victor Stinner :
>
>> I only see one argument against such refactoring: it will be harder to
>> backport/forwardport bugfixes.
>
> I'm opposed for a different reason: I think it will be *har
On Fri, Nov 16, 2012 at 10:06 PM, R. David Murray wrote:
> On Sat, 17 Nov 2012 01:01:52 +0100, Antoine Pitrou
> wrote:
>> On Sat, 17 Nov 2012 00:47:33 +0100
>> mar...@v.loewis.de wrote:
>> >
>> > Zitat von Guido van Rossum :
>> >
>> > > But python-dev seems a poor place to spam with those errors
I filed an issue in the meta tracker about e-mails like the below that
are sent to python-dev. The issue link is here:
http://psf.upfronthosting.co.za/roundup/meta/issue492
--Chris
On Thu, Nov 15, 2012 at 6:39 PM, Python tracker
wrote:
>
>
> An unexpected error occurred during the processing
On Fri, Nov 9, 2012 at 2:57 AM, Chris Withers wrote:
> On 09/11/2012 10:52, Michael Foord wrote:
>>
>> It should be python.exe (yes really).
>
> Hah! Should http://docs.python.org/devguide/ be updated to reflect this or
> does this only affect Mac OS? (or should we correct the build so it doesn't
On Sat, Nov 3, 2012 at 11:18 AM, Terry Reedy wrote:
>
> On 11/3/2012 1:36 PM, Chris Jerdonek wrote:
>>
>> I noticed on an older issue in the tracker that the following deep,
>> in-development link is broken:
>>
>> http://docs.python.org/dev/2.6/library/multipr
1 - 100 of 160 matches
Mail list logo
