On Sat, 7 Apr 2018 17:31:47 -0500
Skip Montanaro wrote:
> It's been a long while since I rebuilt Python from the Git source. I
> tried for the first time the other day. Everything passed except
> test_poplib and test_asyncio. The former just runs and runs and runs.
> Here's the first traceback I e
Agreed with Paul and Steve. A lot of work seems to have gone into the
PEP (congratulations for that), but still the feature brings little to
no additional power to the language while making it more complex.
-1 from me.
Regards
Antoine.
On Tue, 17 Apr 2018 06:55:58 -0700
Steve Dower wrote:
>
On Fri, 20 Apr 2018 13:25:02 +0200
Christoph Groth wrote:
>
> I think that this is the crucial point. If it is indeed a design
> principle of Python that expressions should not have the side-effect of
> assigning names, than the whole discussion of PEP 572 could have been
> stopped early on. I
On Mon, 23 Apr 2018 00:44:44 -0500
Tim Peters wrote:
>
> Which this alternative expresses directly:
>
> if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
> return g
>
> That's so Pythonic I could cry ;-)
It looks like C to me. That won't make me cry (I write C++ code daily
these days),
On Mon, 23 Apr 2018 16:59:35 +0100
Steve Holden wrote:
> On Mon, Apr 23, 2018 at 8:28 AM, Antoine Pitrou wrote:
>
> > On Mon, 23 Apr 2018 00:44:44 -0500
> > Tim Peters wrote:
> > [...]
> >
> > > if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
&
On Tue, 24 Apr 2018 01:06:30 -0500
Tim Peters wrote:
>
> > - does it make Python easier to learn and teach?
>
> By whom? Almost no addition has ever made a language easier to learn
> for raw beginners: every addition is something they eventually need
> to learn. We could make Python easier
On Tue, 24 Apr 2018 16:38:39 +1000
Chris Angelico wrote:
> On Tue, Apr 24, 2018 at 4:27 PM, Antoine Pitrou wrote:
> > On Tue, 24 Apr 2018 01:06:30 -0500
> > Tim Peters wrote:
> >>
> >> > - does it make Python easier to learn and teach?
> >>
&g
On Tue, 24 Apr 2018 01:55:13 -0500
Tim Peters wrote:
> [Antoine]
> > Constructs like "with ..." or "try / except / finally" make the
> > language easier to learn compared to the dances they are meant to
> > replace.
>
> They nevertheless need to be taught & learned (and try/except/finally
> was
On Tue, 24 Apr 2018 23:46:34 +1000
Nick Coghlan wrote:
> On 24 April 2018 at 23:38, Yury Selivanov wrote:
> > I propose to use the following syntax for assignment expressions:
> >
> > ( NAME = expr )
> >
> > I know that it was proposed before and this idea was rejected, because
> > accidental
On Tue, 24 Apr 2018 09:38:33 -0400
Yury Selivanov wrote:
> I propose to use the following syntax for assignment expressions:
>
> ( NAME = expr )
>
> I know that it was proposed before and this idea was rejected, because
> accidentally using '=' in place of '==' is a pain point in
> C/C++/Jav
On Wed, 25 Apr 2018 16:55:43 -0500
Tim Peters wrote:
>
> To my eyes, this is genuinely harder to follow, despite its relative brevity:
>
> while total != (total := total + term):
Does it even work? Perhaps if the goal is to stop when total is NaN,
but otherwise?
> For that reason, the
On Thu, 26 Apr 2018 08:38:51 +1000
Chris Angelico wrote:
> On Thu, Apr 26, 2018 at 8:08 AM, Antoine Pitrou wrote:
> > On Wed, 25 Apr 2018 16:55:43 -0500
> > Tim Peters wrote:
> >>
> >> To my eyes, this is genuinely harder to follow, despite its relative
>
On Wed, 25 Apr 2018 18:55:56 -0500
Tim Peters wrote:
>
> > the shorthand version appears completely bonkers.
>
> I wouldn't go that far, but I already said I wouldn't write it that way.
>
> However, without looking at real code, people are just flat-out
> guessing about how bad - or good - th
On Thu, 26 Apr 2018 10:20:40 +1000
Chris Angelico wrote:
> On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov
> wrote:
> > Just yesterday this snippet was used on python-dev to show how great the
> > new syntax is:
> >
> > my_func(arg, buffer=(buf := [None]*get_size()), size=len(buf))
> >
On Wed, 25 Apr 2018 18:52:34 -0700
Łukasz Langa wrote:
> > On 25 Apr, 2018, at 5:20 PM, Chris Angelico wrote:
> >
> > On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov
> > wrote:
> >> Just yesterday this snippet was used on python-dev to show how great the
> >> new syntax is:
> >>
> >>
On Thu, 26 Apr 2018 17:29:17 +1000
Steven D'Aprano wrote:
> On Thu, Apr 26, 2018 at 07:16:28PM +1200, Greg Ewing wrote:
> > Tim Peters wrote:
> > >As a statement in a program (as opposed to typed at a shell),
> > >"a := 3" has the unnecessary (in that context) property of returning
> > >(and dis
On Thu, 26 Apr 2018 15:34:17 +1000
Steven D'Aprano wrote:
> On Thu, Apr 26, 2018 at 05:22:58PM +1200, Greg Ewing wrote:
> > Łukasz Langa wrote:
> > >What was its own assignment before
> > >now is part of the logic test. This saves on vertical whitespace but makes
> > >parsing and understanding
On Thu, 26 Apr 2018 19:19:05 +1000
Chris Angelico wrote:
> >
> > If such were the need, you could very well make it part of the language
> > specification. We are talking about a trivial optimization that any
> > runtime could easily implement (e.g. if a sequence `DUP_TOP, STORE_FAST,
> > POP_TOP
On Thu, 26 Apr 2018 20:35:20 +0900
"Stephen J. Turnbull" wrote:
> Steven D'Aprano writes:
> > On Wed, Apr 25, 2018 at 09:36:31PM -0500, Ryan Gonzalez wrote:
>
> > > Now, what's the common theme here? **Declarations should be separate
> from
> > > expressions.**
> >
> > Declarations a
On Thu, 26 Apr 2018 22:25:09 +0300
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.
I don't find it that surprisi
On Fri, 27 Apr 2018 09:49:33 -0700
Chris Barker wrote:
> On Tue, Apr 24, 2018 at 2:21 AM, Victor Stinner wrote:
>
> > Even if the C language allows assignments in if, I avoid them, because
> > I regularly have to debug my own code in gdb ;-)
> >
>
> I personally haven't written a lot of C, so
On Fri, 27 Apr 2018 14:13:32 +0200
Victor Stinner wrote:
>
> I don't think that having Python X.Y which introduces backward
> incompatible changes is an issue by itself. We did it multiple times
> during the Python 3 cycle: my PEP 446 (non-inheritable file
> descriptors) and PEP 475 (retry syscal
Le 30/04/2018 à 17:30, Chris Angelico a écrit :
def do_things(fire_missiles=False, plant_flowers=False): ...
do_things(plant_flowers:=True) # whoops!
If you want your API to be keyword-only, make it keyword-only. If you
want a linter that recognizes unused variables, get a linter that
recogni
On Wed, 2 May 2018 11:11:16 +0200
Victor Stinner wrote:
>
> Removing a feature from the C API is more complex, since there is no
> portable way to emit a deprecation warning at compilation. There is
> Py_DEPRECATED() which seems to only be available on GCC (3.1 and
> newer).
It's at least possib
On Wed, 2 May 2018 11:26:35 +0200
Victor Stinner wrote:
>
> Brett Cannon is also working on a standard solution for lazy imports
> since many years:
> https://pypi.org/project/modutil/
> https://snarky.ca/lazy-importing-in-python-3-7/
AFAIK, Mercurial already has its own lazy importer.
> Nick C
On Wed, 02 May 2018 21:24:07 +
Brian Curtin wrote:
> On Wed, May 2, 2018 at 16:55 Ivan Pozdeev via Python-Dev <
> python-dev@python.org> wrote:
>
> > As https://bugs.python.org/issue33257 and
> > https://bugs.python.org/issue33316 showed, Tkinter is broken, for both
> > Py2 and Py3, with both
On Wed, 2 May 2018 23:28:22 +0200
Antoine Pitrou wrote:
> On Wed, 02 May 2018 21:24:07 +
> Brian Curtin wrote:
> > On Wed, May 2, 2018 at 16:55 Ivan Pozdeev via Python-Dev <
> > python-dev@python.org> wrote:
> >
> > > As https://bugs.python.org/issue
OP that Tkinter (and hence
> IDLE) should be scrapped?
>
> On Wed, May 2, 2018 at 2:37 PM, Antoine Pitrou <mailto:solip...@pitrou.net>> wrote:
>
> On Wed, 2 May 2018 23:28:22 +0200
> Antoine Pitrou mailto:solip...@pitrou.net>> wrote:
> > On Wed,
On Wed, 2 May 2018 22:54:04 +0100
Paul Moore wrote:
> On 2 May 2018 at 22:37, Antoine Pitrou wrote:
> > To elaborate a bit: the OP, while angry, produced both a detailed
> > analysis *and* a PR. It's normal to be angry when an advertised
> > feature doesn't work
On Fri, 04 May 2018 00:21:54 +
Ray Donnelly wrote:
>
> Yes, on Windows there's always a python?.dll.
>
> macOS is an interesting one. For Anaconda 5.0 I read somewhere (how's that
> for a useless reference - and perhaps I got the wrong end of the stick)
> that Python for all Unixen should us
On Fri, 4 May 2018 08:23:19 +0100
Steve Holden wrote:
>
> Yup. Tolerance has to have its limits, and this came close to abusive
> behaviour.
>
> I suspect others among us might have been guilty of similar behaviours in
> the past I certainly couldn't cast the first stone), but times change a
On Sat, 5 May 2018 01:43:00 +1000
Steven D'Aprano wrote:
> On Thu, May 03, 2018 at 06:31:03PM +, Brett Cannon wrote:
>
> > No one is saying people can't be upset and if you are ever upset there's
> > something wrong; we're human beings after all. But those of us speaking up
> > about the tone
On Mon, 7 May 2018 12:25:46 +1000
Nick Coghlan wrote:
> On 7 May 2018 at 11:30, Dan Stromberg wrote:
>
> > I'd very much like a live in a world where Jython and IronPython and
> > MicroPython and Cython and Pyjamas can all catch up and implement
> > Python 3.7, 3.8, and so forth.
> >
>
> I'm
On Fri, 04 May 2018 00:21:54 +
Ray Donnelly wrote:
>
> Now that Python 3.7 is around the corner we have a chance to re-evaluate
> this decision. We have received no binary compat. bugs whatsoever due to
> this change (we got a few bugs where people used python-config incorrectly
> either dire
On Mon, 07 May 2018 19:19:28 +
Ryan Gonzalez wrote:
> 10 years feels like a simultaneously long and arbitrary limit. IMO a policy
> of "try to avoid major language features for a while" would work better.
I would remove "for a while". "Try to avoid major language features"
sounds good.
Rega
On Wed, 9 May 2018 14:25:06 +1000
Steven D'Aprano wrote:
> On Mon, May 07, 2018 at 10:23:32PM +0200, Antoine Pitrou wrote:
> > On Mon, 07 May 2018 19:19:28 +
> > Ryan Gonzalez wrote:
> > > 10 years feels like a simultaneously long and arbitrary limit. IMO a
Yes, you don't want this to be a generic utility, rather a helper
library that people can integrate into their command-line applications
to enable such startup caching.
Regards
Antoine.
On Fri, 11 May 2018 17:27:35 +0200
Oleg Broytman wrote:
> On Fri, May 11, 2018 at 07:38:05AM -0700, Chris B
On Sat, 12 May 2018 15:20:11 +0100
Steve Holden wrote:
> Does anyone know why some lines in the tables of
> https://www.python.org/dev/peps/pep-0554/ appear in bold when the markup
> doesn't seem to call for it? I can't find a way to stop this, and it's
> bugging me!
Apparently this may have to d
On Sat, 12 May 2018 15:48:47 +0100
Steve Holden wrote:
> It's certainly true that when I split any of those left-hand cells the
> bizarre emphasis occurs. Still looking for a workaround.
Depending on whether you indent the second line it might be interpreted
as a definition list item:
http://docu
On Tue, 15 May 2018 01:33:18 +0900
INADA Naoki wrote:
>
> It will broke hash randomization.
>
> See also: https://www.cvedetails.com/cve/CVE-2017-11499/
I don't know why it would. The mechanism of pre-initializing a process
which is re-used accross many requests is how most server applications
Le 14/05/2018 à 19:12, INADA Naoki a écrit :
> I'm sorry, the word *will* may be stronger than I thought.
>
> I meant if memory image dumped on disk is used casually,
> it may make easier to make security hole.
>
> For example, if `hg` memory image is reused, and it can be leaked in some
> way,
On Thu, 17 May 2018 09:42:38 -0400
Brett Cannon wrote:
>
> If I understand things correctly, our planned migration to VSTS will
> include eventually automating the signing of the Windows releases so that
> part wont be an issue (which are currently signed manually be Steve).
What part is being "
On Sat, 19 May 2018 17:41:18 -0500
Skip Montanaro wrote:
> On the 3.7 branch, "make test" routinely fails to terminate. (Pretty
> vanilla Ubuntu 17.10 running on a Dell Laptop. Nothing esoteric at all)
> Lately, it's been one of the multiprocessing tests. After a long while
> (~2000 seconds), I ki
On Tue, 22 May 2018 19:10:49 -0500
Tim Peters wrote:
> [Nathaniel Smith ]
> > ...
> > As far as git is concerned, the main repo on github, your fork on
> > github, and your local repo are 3 independent repositories, equally
> > valid. The relationships between them are purely a matter of
> > conv
Hi,
While PEP 574 (pickle protocol 5 with out-of-band data) is still in
draft status, I've made available an implementation in branch "pickle5"
in my GitHub fork of CPython:
https://github.com/pitrou/cpython/tree/pickle5
Also I've published an experimental backport on PyPI, for Python 3.6
and 3.
It's worth nothing that OrderedDict already supports reversed().
The argument could go both ways:
1. dict is similar to OrderedDict nowadays, so it should support
reversed() too;
2. you can use OrderedDict to signal explicitly that you care about
ordering; no need to add anything to dict.
On Fri, 25 May 2018 10:36:08 -0700
Raymond Hettinger wrote:
> > On May 24, 2018, at 10:57 AM, Antoine Pitrou wrote:
> >
> > While PEP 574 (pickle protocol 5 with out-of-band data) is still in
> > draft status, I've made available an implementation in branch "
On Fri, 25 May 2018 14:50:57 -0600
Neil Schemenauer wrote:
> On 2018-05-25, Antoine Pitrou wrote:
> > Do you have something specific in mind?
>
> I think compressed by default is a good idea. My quick proposal:
>
> - Use fast compression like lz4 or zlib with Z_BE
On Sat, 26 May 2018 18:42:42 +0200
Olivier Grisel wrote:
>
> However adding lz4.LZ4File to the standard library in addition to
> gzip.GzipFile and lzma.LZMAFile is probably a good idea as LZ4 is really
> fast compared to zlib/gzip. But this is not related to PEP 574.
If we go that way, we may pr
+1 for withdrawing it. It's much too late in the 2.7 maintenance
schedule to start bothering with such a large and perilous backport.
Regards
Antoine.
On Wed, 30 May 2018 16:28:22 +0200
Victor Stinner wrote:
> Hi,
>
> tl; dr I will withdraw the PEP 546 in one week if noboy shows up to
> f
On Mon, 4 Jun 2018 17:03:27 +0200
Victor Stinner wrote:
>
> At this point, I have no opinion about the event :-) I just guess that
> it should make GitHub more sustainable since Microsoft is a big
> company with money and interest in GitHub. I'm also confident that
> nothing will change soon. I
6:28 -0700
Guido van Rossum wrote:
> On Mon, Jun 4, 2018 at 8:40 AM, Antoine Pitrou wrote:
>
> >
> > On Mon, 4 Jun 2018 17:03:27 +0200
> > Victor Stinner wrote:
> > >
> > > At this point, I have no opinion about the event :-) I just guess that
> > >
Le 04/06/2018 à 19:49, Mariatta Wijaya a écrit :
> I think we shouldn't be speculating or making guesses.
> If people are concerned with how Microsoft will manage GitHub, please
> talk to Microsoft or GitHub representative, and not gossip in python-dev.
What would talking to a MS or GH representa
On Fri, 8 Jun 2018 09:48:03 +0200
Victor Stinner wrote:
>
> Question: Do you think that bugs spotted by a GC collection are common
> enough to change the GC thresholds in development mode (new -X dev
> flag of Python 3.7)?
I don't think replacing a more-or-less arbitrary value with another
more-
On Mon, 18 Jun 2018 06:13:15 -0700
Ethan Furman wrote:
> I'm sure we've already had this conversation, but my google-fu is failing me.
>
> Can someone provide a link to a discussion explaining why the new ordering of
> dictionaries does not defeat the
> hash-randomization non-ordering we added
On Mon, 18 Jun 2018 19:49:28 +0200
Stefan Behnel wrote:
> Victor Stinner schrieb am 18.06.2018 um 15:09:
> > I tried two options to add support for FASTCALL on calling an object:
> > add a flag in tp_flags and reuse tp_call, or add a new tp_fastcall
> > slot. I failed to implement correctly any of
Hi Jeroen,
On Wed, 20 Jun 2018 10:53:18 +0200
Jeroen Demeyer wrote:
>
> PEP 579 is an informational meta-PEP, listing some of the issues with
> functions/methods implemented in C. The idea is to create several PEPs
> each fix some part of the issues mentioned in PEP 579.
>
> PEP 580 is a st
On Wed, 20 Jun 2018 16:32:09 +0200
Jeroen Demeyer wrote:
>
> > - there's CCALL_OBJCLASS and CCALL_SLICE_SELF which have, well,
> >non-obvious behaviour (especially the latter), especially as it is
> >conditioned on the value of other fields or flags
>
> It's actually quite obvious when
On Wed, 20 Jun 2018 18:09:00 +0200
Victor Stinner wrote:
>
> > If we can't at Python 3.7, I think we should do it at 3.8.
>
> What's the rationale to make it public in 3.7? Can't it wait for 3.8?
> The new PEPs target 3.8 anyway, no?
>
> IMHO it's too late for 3.7.
Agreed with Victor. Also
On Thu, 21 Jun 2018 13:25:19 +0200
Jeroen Demeyer wrote:
> Currently, we have:
>
> >>> [].append == [].append
> False
>
> However, with a Python class:
>
> >>> class List(list):
> ... def append(self, x): super().append(x)
> >>> List().append == List().append
> True
>
> In the for
On Thu, 21 Jun 2018 13:53:53 +0200
Jeroen Demeyer wrote:
> On 2018-06-21 13:33, Ivan Pozdeev via Python-Dev wrote:
> > First, tell us what problem you're solving.
>
> There is no specific problem I want to solve here. I just noticed an
> inconsistency and I wondered if it would be OK to chang
Hi Jake,
On Thu, 21 Jun 2018 09:18:30 -0600
Jake Edge wrote:
>
> The starting point is here: https://lwn.net/Articles/754152/ That is
> an overview article with links to the individual articles. Here are
> the articles since my post on Monday (which is here:
> https://lwn.net/ml/python-dev/2
On Sat, 23 Jun 2018 00:22:33 +1000
Nick Coghlan wrote:
> On 22 June 2018 at 02:26, Antoine Pitrou wrote:
> > Indeed. But, for a syntax addition such as PEP 572, I think it would be
> > a good idea to ask their opinion to teaching/education specialists.
> >
> >
On Tue, 26 Jun 2018 11:00:48 +0200
Jeroen Demeyer wrote:
> Hello,
>
> On https://github.com/python/cpython/pull/7909 I encountered friction
> for a PR which I expected to be uncontroversial: it just moves some code
> without changing any functionality.
>
> So basically my question is: is there
Why is this discussion talking about comprehensions at all?
Is there a decent use case for using assignments in comprehensions (as
opposed to language lawyering or deliberate obfuscation)?
Regards
Antoine.
On Thu, 28 Jun 2018 01:25:14 +1200
Greg Ewing wrote:
> Ivan Pozdeev via Python-Dev wro
On Wed, 27 Jun 2018 09:18:24 -0400 (EDT)
Charalampos Stratakis wrote:
>
> My question is, if there is any incentive to try and ask for
> modernization/amendment of the standards?
> I really doubt that any linux distro at that point can be considered lsb
> compliant at least from the
> python s
On Sat, 23 May 2015 20:14:56 -0700
Larry Hastings wrote:
>
> On 05/23/2015 07:38 PM, Nick Coghlan wrote:
> > Eric clarified for me that Larry was considering granting a feature
> > freeze exemption to defer landing this to beta 2 while Eric tracked
> > down a segfault bug in the current patch tha
On Mon, 25 May 2015 17:30:02 -0700
Larry Hastings wrote:
>
> So, in all three cases it's work that's been under development for a
> while. These people did this work out of the kindness of their hearts,
> to make Python better. As a community we want to encourage that and
> make sure these d
On Wed, 27 May 2015 18:34:29 +1000
Nick Coghlan wrote:
>
> I'd actually like to pursue a more nuanced view of what's permitted in
> maintenance releases, based on a combination of the language moratorium
> PEP, and an approach inspired by PEP 466, requiring that every feature
> added in a mainten
On Wed, 27 May 2015 17:15:39 -0400
Terry Reedy wrote:
> On 5/27/2015 4:16 AM, Antoine Pitrou wrote:
>
> > I second that sentiment. But it strikes me that we're doing this
> > because our release frequency is completely inadapted. If we had
> > feature releases,
On Thu, 28 May 2015 08:48:11 +1000
Nick Coghlan wrote:
>
> I just remembered one of the biggest causes of pain: Windows binaries for
> projects that aren't using the stable ABI. It used to regularly take 6+
> months for the Windows ecosystem to catch up after each 2.x release.
You're right, comp
On Fri, 29 May 2015 21:39:55 +1000
Nick Coghlan wrote:
> The key is whether or not we can readily notify people when the "most
> recent known good" hash *changes*, and less about the mechanics of how we
> then record the history of which commits *were* stable, or the identity of
> the most recent
On Fri, 29 May 2015 18:36:02 +1000
Steven D'Aprano wrote:
>
> The point is, in the Linux circles I move in, this idea of single file
> installation would be about as popular as a police raid at a rave club.
This is frankly not true. There are many programs (e.g. games) which are
not available
On Sat, 30 May 2015 01:49:10 +0200
Christian Heimes wrote:
> For performance patches we have to consider our responsibility for the
> environment. Every improvement means more speed and less power
> consumption. Python runs of hundreds of thousands of machines in the
> cloud. Python 2.7 will be us
On Sat, 30 May 2015 10:34:15 +1000
Nick Coghlan wrote:
> On 30 May 2015 09:57, "Antoine Pitrou" wrote:
> >
> > On Sat, 30 May 2015 01:49:10 +0200
> > Christian Heimes wrote:
> > > For performance patches we have to consider our responsibility for the
&g
On Sat, 30 May 2015 18:55:20 +1000
Nick Coghlan wrote:
> On 30 May 2015 10:46, "Alexander Walters" wrote:
> >
> > Python is a giant cache-miss generator. A little performance boost on the
> > opt-code dispatch isn't going to change that much. If we really do care
> > about improving python to
On Sat, 30 May 2015 20:52:21 +1000
Chris Angelico wrote:
>
> Suppose someone came up with a magic patch that makes the CPython core
> run 25% faster. No downsides, just 25% faster across the board. I
> wouldn't pay money for it on the sole basis of expecting to make that
> back in reduced electri
On Sat, 30 May 2015 21:20:56 +1000
Nick Coghlan wrote:
> Given the extensive complaints about the lack of corporate
> contribution to upstream CPython maintenance, the hostile reaction to
> a concrete proposal for such ongoing contributions has been both
> incredibly surprising *and* disappointing
Le 30/05/2015 13:51, Stephen J. Turnbull a écrit :
> Antoine Pitrou writes:
> > On Sat, 30 May 2015 01:49:10 +0200
> > Christian Heimes wrote:
> > > For performance patches we have to consider our responsibility for the
> > > environment. Every improvemen
Hi Christian,
> Antoine,
>
> now your are putting it over the top. You make it sound like I'm some
> crazy environmentalist or eco-warrior. Well, I'm not.
I apologize for misrepresenting your position.
I still don't think discussing environmental matters is really
productive here, though :-)
R
On Mon, 1 Jun 2015 16:38:35 +0200
Petr Viktorin wrote:
> Hello,
> The new test_importlib.extension.test_loader is currently leaking
> references, (issue24268). There is a simple hack to stop this, but I'm
> inclined to not apply quick hacks and rather dig into the root cause.
> (It's a test module
On Mon, 1 Jun 2015 17:52:13 +0200
Petr Viktorin wrote:
> On Mon, Jun 1, 2015 at 5:33 PM, Antoine Pitrou wrote:
> > On Mon, 1 Jun 2015 16:38:35 +0200
> > Petr Viktorin wrote:
> [...]
> >> The nice way out would be taking advantage of PEP 442: xxlimited.Xxo
> >&
On Mon, 01 Jun 2015 12:09:37 -0400
Benjamin Peterson wrote:
>
> I thought all the slots were supposed to be available through the stable
> ABI, since you need them to properly define c types.
You're right, I was thinking specifically about the ABI versioning
issues (which I exposed in my reply t
On Tue, 2 Jun 2015 21:09:52 +0200
Petr Viktorin wrote:
> On Mon, Jun 1, 2015 at 6:00 PM, Antoine Pitrou wrote:
> [...]
> > I think we have been laxist with additions to the stable ABI:
> > apparently, they should be conditioned on the API version requested by
> > th
On Tue, 02 Jun 2015 21:20:10 +
Brett Cannon wrote:
>
> I vaguely remember people suggesting writing the minimal zip reading code
> in C but I can't remember why since we have I/O access in importlib through
> _io and thus it's really just the pulling apart of the zip file to get at
> the file
On Mon, 08 Jun 2015 21:39:17 +
andrew.kuchling wrote:
> https://hg.python.org/cpython/rev/15ee0e7078e3
> changeset: 96555:15ee0e7078e3
> branch: 3.4
> parent: 96552:2b78227974fa
> user:Andrew Kuchling
> date:Mon Jun 08 17:35:45 2015 -0400
> summary:
> #23891: add
On Sat, 20 Jun 2015 21:16:48 +0200
"M.-A. Lemburg" wrote:
> On 20.06.2015 09:30, Victor Stinner wrote:
> > Hi,
> >
> > I didn't get much feedback on this PEP. Since the Python 3.6 branch is
> > open (default), it's probably better to push such change in the
> > beginning of the 3.6 cycle, to catc
Hello Elizabeth,
On Thu, 25 Jun 2015 20:23:44 +0300
Elizabeth Shashkova wrote:
> Hello everybody!
>
> When I call fork() inside a daemon thread, the main thread in the child
> process has the "daemon" property set to True. This is very confusing,
> since the program keeps running while the only
On Mon, 6 Jul 2015 14:22:46 +1000
Nick Coghlan wrote:
>
> The main change from the last version discussed on python-ideas
Was it discussed there? That list has become totally useless, I've
stopped following it.
> * modify the ``ssl`` module to read the ``PYTHONHTTPSVERIFY`` environment
> vari
On Mon, 6 Jul 2015 23:22:09 +1000
Nick Coghlan wrote:
> On 6 Jul 2015 20:23, "Antoine Pitrou" wrote:
> >
> > On Mon, 6 Jul 2015 14:22:46 +1000
> > Nick Coghlan wrote:
> > >
> > > The main change from the last version discussed on python-id
On Tue, 7 Jul 2015 12:04:34 +0200
Maciej Fijalkowski wrote:
> I must say I completely fail to understand the procedures under which
> python is developed. If the change (unreviewed, just randomly applied)
> causes crashes, then surely it should be reverted first and continued
> on bug tracker inst
On Tue, 7 Jul 2015 14:14:49 +0200
Guido van Rossum wrote:
> FYI, do we have any indication that Raymond even read the comment? IIRC he
> doesn't regularly read python-dev. I also don't think code review comments
> ought to go to python-dev; the commiters list would seem more appropriate?
Well, do
On Wed, 8 Jul 2015 00:10:09 +1000
Nick Coghlan wrote:
>
> It's OK if folks aren't interested in participating in the noisy early
> stages of that process - that's why the activity was long since moved
> out to a dedicated list. It's not OK to make the jump from "I don't
> consider participating i
On Thu, 9 Jul 2015 20:57:33 +1000
Nick Coghlan wrote:
>
> As Guido suggested, would you be willing to take on the BDFL-Delegate
> task for this? It definitely seems appropriate given the errors and
> omissions you've already found :)
Fine. I'll take a look again and come up with questions, if I
On Wed, 15 Jul 2015 10:22:14 +1200
Robert Collins wrote:
>
> For clarity, I think we should:
> - remove the assret check, it is I think spurious.
> - add a set of functions to the mock module that should be used in
> preference to Mock.assert*
> - mark the Mock.assert* functions as PendingDepr
On Fri, 17 Jul 2015 06:59:16 +1000
Ben Finney wrote:
>
> +1.
>
> These checks are a good thing, but they belong in a linter tool not as
> aliases in the API.
Practicality beats purity. Unless you have been actually *bitten* by
those checks I don't think there's any serious reason to complain.
On Fri, 17 Jul 2015 08:30:59 +1000
Ben Finney wrote:
> Antoine Pitrou writes:
>
> > On Fri, 17 Jul 2015 06:59:16 +1000
> > Ben Finney wrote:
> > >
> > > +1.
> > >
> > > These checks are a good thing, but they belong in a linter tool not a
On Wed, 15 Jul 2015 20:39:37 +1200
Robert Collins wrote:
> On 15 July 2015 at 19:17, Antoine Pitrou wrote:
> > On Wed, 15 Jul 2015 10:22:14 +1200
> > Robert Collins wrote:
> >>
> >> For clarity, I think we should:
> >> - remove the assret check, it
On Wed, 15 Jul 2015 07:40:57 +1200
Robert Collins wrote:
> On 15 July 2015 at 07:39, Paul Moore wrote:
> > On 14 July 2015 at 20:27, Robert Collins wrote:
>
> >>> In effect, this patch is "reserving" all attributes starting with
> >>> "assert" or "assret" as actual methods of the mock object,
On Fri, 17 Jul 2015 11:35:53 +1200
Alexander wrote:
>
> I do not want to read mistyped code from other developers and try to
> guess whether it will work properly or not.
You don't have to guess anything. If it's mistyped, either it raises
AttributeError (because it starts with "assert_"), or it
401 - 500 of 4909 matches
Mail list logo
