On Tue, May 28, 2013 at 5:40 PM, Antoine Pitrou wrote:
> On Tue, 28 May 2013 23:29:46 +0200 (CEST)
> brett.cannon wrote:
>>
>> +.. class:: ModuleManager(name)
>> +
>> +A :term:`context manager` which provides the module to load. The module
>> will
>> +either come from :attr:`sys.modules`
On May 29, 2013 1:09 AM, "Nick Coghlan" wrote:
>
> On Wed, May 29, 2013 at 10:14 AM, Brett Cannon wrote:
> >> (FWIW, I think "ModuleManager" is a rather bad name :-)
> >
> > I'm open to suggestions, but the thing does manage the
On Wed, May 29, 2013 at 10:34 AM, Nick Coghlan wrote:
> On Wed, May 29, 2013 at 11:04 PM, Brett Cannon wrote:
>>> with initialise_module(name) as m:
>>> # Module initialisation code goes here
>>> # Module is rolled back if initialisat
On Wed, May 29, 2013 at 11:58 AM, R. David Murray wrote:
> On Thu, 30 May 2013 00:59:02 +1000, Nick Coghlan wrote:
>> On Thu, May 30, 2013 at 12:47 AM, Brett Cannon wrote:
>> > I am willing to compromise to module_to_initialize, module_to_init, or
>> > module_to_loa
On Wed, May 29, 2013 at 12:49 PM, R. David Murray wrote:
> On Wed, 29 May 2013 12:25:45 -0400, Brett Cannon wrote:
>> In case you want to suggest a name, the context manager returns the
>> module that should be initialized/loaded. So typical usage will be::
>>
>>
On Wed, May 29, 2013 at 2:56 PM, R. David Murray wrote:
> On Wed, 29 May 2013 20:10:44 +0200, Antoine Pitrou
> wrote:
>> On Wed, 29 May 2013 12:55:01 -0400
>> Brett Cannon wrote:
>> > > Perhaps 'managed_module'?
>> >
>> > managed_m
9cc1b04713e
> user: Brett Cannon
> date:Fri May 31 18:11:17 2013 -0400
> summary:
> Add a reset_name argument to importlib.util.module_to_load in order to
> control whether to reset the module's __name__ attribute in case a
> reload is being done.
>
&
On Mon, Jun 3, 2013 at 1:04 PM, Barry Warsaw wrote:
> On Jun 03, 2013, at 02:21 PM, Donald Stufft wrote:
>
> >The other additional comment I'd like to throw in here is that if we don't
> >bundle SSL certs I think we should still verify by default (which means
> HTTPS
> >urls will throw an error b
I think this CL introduced a memory leak. The daily leak report went from 0
to not 0 between June 4 and June 5 and this is the only CL that touched C
code.
On Wed, Jun 5, 2013 at 6:31 PM, richard.oudkerk
wrote:
> http://hg.python.org/cpython/rev/0410bf251e10
> changeset: 84045:0410bf251e10
> u
On Fri, Jun 7, 2013 at 10:27 AM, Thomas Wouters wrote:
>
> On Wed, Jun 5, 2013 at 3:20 AM, lukasz.langa
> wrote:
>
>> +from weakref import WeakKeyDictionary
>>
>
> FYI, this change exposes a bug in the atexit module involving
> subinterpreters, causing the refleaks reported by Antoine's daily re
On Tue, Jun 11, 2013 at 1:57 AM, Jeff Sickel wrote:
> I have a set of patches I've developed based on the 2.7 branch that
> provides a working port of Python 2.7.5 to Plan 9 386 and amd64 builds (an
> arm version is mostly working, but will need a few more updates before
> being hauled off on the
rev/c4d7228421df
> changeset: 84106:c4d7228421df
> user: Brett Cannon
> date:Wed Jun 12 20:12:30 2013 -0400
> summary:
> Move test___all__ over to unittest.main() and use ModuleNotFoundError
>
> files:
> Lib/test/regrtest.py | 16
>
On Fri, Jun 14, 2013 at 3:12 PM, Martin Schultz wrote:
> As much as I love python, the following drives me crazy, and I would wish
> that some future version would come up with a more consistent approach for
> this. And please don't reply with "Too bad if you don't know what type your
> data are.
Ethan, did you forget to run ``hg add`` before committing? If not then why
the heck did we argue over enums for so long if this was all it took to
make everyone happy? =)
On Fri, Jun 14, 2013 at 3:31 AM, ethan.furman wrote:
> http://hg.python.org/cpython/rev/fae92309c3be
> changeset: 84117:fae
So the best place to ask this question is python-list and not python-dev as
this is about developing *for* Python and not *with* Python.
On Mon, Jun 17, 2013 at 12:42 PM, Aditya Avinash wrote:
> Hi. This is the last place where I want to ask a question. I have searched
> for lots of tutorials a
On Wed, Jun 19, 2013 at 11:20 PM, senthil.kumaran <
python-check...@python.org> wrote:
> http://hg.python.org/cpython/rev/dfead0696a71
> changeset: 84224:dfead0696a71
> branch: 3.3
> parent: 84221:0113247f894b
> user:Senthil Kumaran
> date:Wed Jun 19 22:19:46 2013 -050
On Thu, Jun 20, 2013 at 10:14 AM, Eric V. Smith wrote:
> On 6/20/2013 9:40 AM, Nick Coghlan wrote:
> > On 20 June 2013 23:29, Christian Heimes wrote:
> >> Am 20.06.2013 15:21, schrieb Florent:
> >>> we already have "_pyio.py", we could have "_pystat.py".
> >>
> >> Works for me.
> >
> > I suggest
On Mon, Jun 24, 2013 at 4:43 PM, Benjamin Peterson wrote:
> 2013/6/24 Maciej Fijalkowski :
> > On Sun, Jun 23, 2013 at 6:14 PM, R. David Murray
> wrote:
> >> On Sun, 23 Jun 2013 17:40:13 +0200, Maciej Fijalkowski <
> fij...@gmail.com> wrote:
> >>> On
This fix is still not correct as warnings.formatwarning should not be
overridden, only showwarning can be.
On Jun 24, 2013 6:18 PM, "victor.stinner"
wrote:
> http://hg.python.org/cpython/rev/2a9e1eb3719c
> changeset: 84330:2a9e1eb3719c
> user:Victor Stinner
> date:Tue Jun 25 00
On Thu, Jul 4, 2013 at 8:13 AM, Chris Withers wrote:
> On 04/07/2013 12:59, Christian Heimes wrote:
>
>> Am 04.07.2013 13:21, schrieb Chris Withers:
>>
>>> There doesn't appear to be any way in Python 3 to do this, which is a
>>> little surprising and frustrating...
>>>
>>> What am I missing here?
On Sat, Jul 13, 2013 at 4:24 AM, Michael Foord wrote:
>
> On 13 Jul 2013, at 07:41, Terry Reedy wrote:
>
> > On 7/13/2013 12:10 AM, Eric Snow wrote:
> >>
> >> On Feb 27, 2013 4:31 AM, "Michael Foord" >
> >> > +1 PLY is capable and well tried-and-tested. We used it in Resolver
> >> One to impleme
On Sun, Jul 14, 2013 at 2:54 AM, Nick Coghlan wrote:
> On 13 July 2013 23:26, David Beazley wrote:
>
>> I'm in favor of PLY going into stdlib with the caveat that there are some
>> things about it that should probably be cleaned up and modernized. For
>> instance, the method by which it writes
On Sun, Jul 14, 2013 at 7:09 AM, Nick Coghlan wrote:
> On 14 July 2013 18:11, Nick Coghlan wrote:
>
>> Currently, the naming section of PEP 8 doesn't say very much about what a
>> leading underscore *means* in the Python standard library.
>>
>> I would like to add a new "Private interfaces" subs
On Sun, Jul 14, 2013 at 8:01 PM, Cameron Simpson wrote:
> On 15Jul2013 09:48, Steven D'Aprano wrote:
> | On 14/07/13 21:09, Nick Coghlan wrote:
> |
> | >Slight adjustment to the proposed wording to ensure completely
> undocumented
> | >modules are also considered private:
> |
> | -1 on this adju
On Tue, Jul 16, 2013 at 9:07 PM, Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Jul 16, 2013, at 07:34 PM, Tres Seaver wrote:
>
> >On 07/16/2013 07:09 AM, Nick Coghlan wrote:
> >
> >> I did find it interesting that we *don't* explicitly advise against
> >> the use
On Wed, Jul 24, 2013 at 5:12 AM, Bohuslav Kabrda wrote:
> Hi all,
> in recent days, there has been a discussion on fedora-devel (see thread
> [1]) about moving to Python 3 as a default.
> I'd really love to hear opinions on the matter from the upstream, mainly
> regarding these two points (that a
On Thu, Jul 25, 2013 at 11:18 AM, Eli Bendersky wrote:
>
>
>
> On Thu, Jul 25, 2013 at 7:48 AM, Brian Curtin wrote:
>
>> On Thu, Jul 25, 2013 at 9:37 AM, Christian Heimes
>> wrote:
>> > Am 25.07.2013 16:29, schrieb Eli Bendersky:
>> >> Hi all,
>> >>
>> >> I've been looking for a Github mirror f
On Thu, Jul 25, 2013 at 6:56 PM, Christian Heimes wrote:
> Am 26.07.2013 00:32, schrieb Terry Reedy:
> > I found the answer here
> > https://docs.google.com/file/d/0B5wQCOK_TiRiMWVqQ0xPaDEzbkU/edit
> > Coverity Integrity Level 1 is 1 (defect/1000 lines)
> > Level 2 is .1 (we have passed that)
> >
On Fri, Jul 26, 2013 at 8:56 AM, Eli Bendersky wrote:
> Just a quick question - is there a chance to convince Coverity to detect
> Python refcounting leaks in C API code :-) ?
>
You can always ask. =)
> This could be useful not only for Python but for extensions too. As it
> stands now, Coveri
On Mon, Jul 29, 2013 at 1:15 PM, Christian Heimes wrote:
> Hi,
>
> I have done some experiments with GCC's gcov and lcov to get the C code
> coverage of our unit test suite. You may find today's report at
>
> http://tiran.bitbucket.org/python-lcov/
Thanks!
I took a quick poke around and it se
On Mon, Jul 29, 2013 at 3:31 PM, Christian Heimes wrote:
> Am 29.07.2013 19:58, schrieb Brett Cannon:
> > I took a quick poke around and it seems some things are legitimately not
> > being executed, while others are error conditions that we wouldn't
> > expect to occ
On Tue, Jul 30, 2013 at 8:28 PM, Christian Heimes wrote:
> Am 29.07.2013 21:48, schrieb Antoine Pitrou:
> > Ideally, we should run coverage runs on different systems (Unices,
> > Windows...) and merge the results together, so that we know which paths
> > are really uncovered.
>
> I don't that is e
On Thu, Aug 1, 2013 at 12:58 PM, Alexander Shorin wrote:
> Hi Steven,
>
> On Thu, Aug 1, 2013 at 7:06 PM, Steven D'Aprano
> wrote:
> > Hi Alexander,
> >
> > On 02/08/13 00:48, Alexander Shorin wrote:
> >>
> >> Hi Ronald,
> >>
> >> I understand this, but I'm a bit confused about fate of lambdas w
On Tue, Aug 6, 2013 at 12:59 AM, Nick Coghlan wrote:
> On 6 August 2013 09:53, Larry Hastings wrote:
> > On 08/05/2013 02:55 AM, Nick Coghlan wrote:
> > On 5 August 2013 18:48, Larry Hastings wrote:
> >
> > Question 0: How should we integrate Clinic into the build process?
> >
> > Isn't solving
lock per
> module (mentioned in my initial email) and watched the presentation by
> Brett Cannon (BTW, I could not find the diagram explained during the
> presentation, anyone knows if it's available somewhere?).
>
http://prezi.com/mqptpza9xbic/?utm_campaign=share&utm_medium=c
At the PyCon CA sprint someone discovered the formatter module had somewhat
low code coverage. We discovered this is because it's tested by
test_sundry, i.e. it's tested by importing it and that's it.
We then realized that it isn't really used by anyone (pydoc uses it but it
should have been using
On Mon, Aug 12, 2013 at 10:10 PM, Arnaud Fontaine <
arnaud.fonta...@nexedi.com> wrote:
> Brett Cannon writes:
> > On Mon, Aug 12, 2013 at 5:12 AM, Arnaud Fontaine <
> arnaud.fonta...@nexedi.com wrote:
> >> Yes, I saw the bug report and its patch implementing t
On Tue, Aug 13, 2013 at 6:34 AM, Serhiy Storchaka wrote:
> 12.08.13 22:22, Brett Cannon написав(ла):
>
> I have created
> http://bugs.python.org/**issue18716<http://bugs.python.org/issue18716>to
> deprecate the
>> formatter module for removal in Python 3.6
On Tue, Aug 13, 2013 at 10:22 PM, Steven D'Aprano wrote:
> On 13/08/13 23:36, Brett Cannon wrote:
>
>> On Tue, Aug 13, 2013 at 6:34 AM, Serhiy Storchaka > >wrote:
>>
>> 12.08.13 22:22, Brett Cannon написав(ла):
>>>
>>> I have cr
On Wed, Aug 14, 2013 at 11:47 AM, Nick Coghlan wrote:
> On 14 August 2013 11:08, Brett Cannon wrote:
> > We take adding a module to the stdlib very seriously for all of these
> > reasons and yet people seem to forget that the exact same reasons apply
> to
> > modul
On Wed, Aug 14, 2013 at 12:09 PM, Nick Coghlan wrote:
> On 14 August 2013 11:55, Brett Cannon wrote:
> > On Wed, Aug 14, 2013 at 11:47 AM, Nick Coghlan
> wrote:
> >>
> >> On 14 August 2013 11:08, Brett Cannon wrote:
> >> > We take adding a module to
On Wed, Aug 14, 2013 at 1:50 PM, Chris Angelico wrote:
> On Wed, Aug 14, 2013 at 6:42 PM, Nick Coghlan wrote:
> > That would be PEP 4 :)
>
> What's the normal way to update a PEP?
>
> ... proposals for deprecating modules MUST be made by providing a
> change to the text of this PEP, whic
On Thu, Aug 15, 2013 at 5:22 AM, Antoine Pitrou wrote:
> On Thu, 15 Aug 2013 11:16:20 +0200
> Victor Stinner wrote:
> > 2013/8/15 Antoine Pitrou :
> > > We don't have any substantial change in store for an eventual "Python
> > > 4", so it's quite a remote hypothesis right now.
> >
> > I prefered
On Thu, Aug 15, 2013 at 8:29 AM, R. David Murray wrote:
> On Thu, 15 Aug 2013 11:22:14 +0200, Antoine Pitrou
> wrote:
> > On Thu, 15 Aug 2013 11:16:20 +0200
> > Victor Stinner wrote:
> > > 2013/8/15 Antoine Pitrou :
> > > > We don't have any substantial change in store for an eventual "Python
>
On Thu, Aug 15, 2013 at 8:36 AM, Antoine Pitrou wrote:
> On Thu, 15 Aug 2013 08:29:35 -0400
> "R. David Murray" wrote:
>
> > On Thu, 15 Aug 2013 11:22:14 +0200, Antoine Pitrou
> wrote:
> > > On Thu, 15 Aug 2013 11:16:20 +0200
> > > Victor Stinner wrote:
> > > > 2013/8/15 Antoine Pitrou :
> > >
On Thu, Aug 15, 2013 at 9:15 AM, Ezio Melotti wrote:
> Hi,
>
> On Thu, Aug 15, 2013 at 3:29 PM, R. David Murray
> wrote:
> > On Thu, 15 Aug 2013 11:22:14 +0200, Antoine Pitrou
> wrote:
> >> On Thu, 15 Aug 2013 11:16:20 +0200
> >> Victor Stinner wrote:
> >> > 2013/8/15 Antoine Pitrou :
> >> > >
On Tue, Aug 20, 2013 at 8:33 PM, Tim Peters wrote:
> [Tim, wondering why the 3.2 branch isn't "inactive"]
> >> ...
> >> What is gained by _not_ merging here? I don't see it.
>
> [Antoine Pitrou]
> > Perhaps Georg doesn't like merges? ;-)
> > I suppose what's gained is "one less command to type".
2 into 3.3,
> >> then merge 3.3 into default? I'd be happy to do that. I'd throw away
> >> all the merge changes except for adding the v3,2.5 tag to .hgtags.
> >>
> >> The only active branches remaining would be `default` and 2.7, which
> >> is
I just committed a change to the benchmarks suite so that there is no
longer a translation step to allow running under Python 3. Should make it
much easier to just keep a checkout lying around to use for both Python 2
and 3 benchmarking.
___
Python-Dev ma
g.python.org/cpython/rev/7d30ecf5c916
> > changeset: 85339:7d30ecf5c916
> > parent: 85336:391f36ef461a
> > parent: 85337:ddd610cb65ef
> > user:Brett Cannon
> > date:Fri Aug 23 11:52:19 2013 -0400
> > summary:
> > mer
On Wed, Aug 28, 2013 at 8:16 PM, Victor Stinner wrote:
> Hi,
>
> Thanks to the PEP 445, it becomes possible to trace easily memory
> allocations. I propose to add a new tracemalloc module computing the
> memory usage per file and per line number. It has also a private
> method to retrieve the loca
On Mon, Sep 9, 2013 at 8:02 AM, Larry Hastings wrote:
>
> On behalf of the Python development team, I'm chuffed to announce the
> second alpha release of Python 3.4.
>
> This is a preview release, and its use is not recommended for
> production settings.
>
> Python 3.4 includes a range of improve
On Wed, Sep 11, 2013 at 8:46 AM, Victor Stinner wrote:
> Use your microphone, say "python" and save the file in your favorite
> file format. Try for example Audacity. I suppose that you don't need
> specific audio content and you don't need a huge file.
>
And if you don't want your voice in the t
On Mon, Sep 16, 2013 at 3:45 PM, Antoine Pitrou wrote:
> On Mon, 16 Sep 2013 19:06:37 +0200
> Charles-François Natali wrote:
> > 2013/9/16 Antoine Pitrou :
> > > Le Sun, 15 Sep 2013 06:46:08 -0700,
> > > Ethan Furman a écrit :
> > >> I see PEP 428 is both targeted at 3.4 and still in draft stat
On Tue, Sep 17, 2013 at 2:45 PM, Glenn Linderman wrote:
> On 9/17/2013 10:51 AM, Guido van Rossum wrote:
>
> But only the PSF has the list of original contributors and their licenses.
>
>
> So can that list be made public, and available in multiple archives?
>
Technically it already is public ba
On Sun, Sep 22, 2013 at 8:53 AM, Steven D'Aprano wrote:
> On Sun, Sep 22, 2013 at 10:20:46AM +0200, Antoine Pitrou wrote:
> > On Sun, 22 Sep 2013 13:13:04 +1000
> > Steven D'Aprano wrote:
> > > Hi all,
> > >
> > > I have a question about how I should manage documentation for the
> > > statistics
cc'ing Jeremy Hylton who made the decision to use Zephyr.
On Wed, Sep 25, 2013 at 9:15 AM, Eli Bendersky wrote:
> Hello,
>
> Some history (as best as I could collect it) followed by a question:
>
> Before Python 2.5, the ast stdlib module was auto generated by a script
> named astgen.py from a
On Wed, Sep 25, 2013 at 9:28 AM, Benjamin Peterson wrote:
> 2013/9/25 Eli Bendersky :
> > Hello,
> >
> > Some history (as best as I could collect it) followed by a question:
> >
> > Before Python 2.5, the ast stdlib module was auto generated by a script
> > named astgen.py from a textual AST defin
This list is for the developing *of *Python, not it's use. You can try
asking on python-list for some help.
On Wed, Sep 25, 2013 at 4:07 AM, alok bhan wrote:
> Hi All
>
> I need help in installing python development packages (python27-devel) on
> Centos5.8. Upgrading hardware is not an option a
On Wed, Sep 25, 2013 at 7:15 PM, Donald Stufft wrote:
>
> On Sep 25, 2013, at 7:04 PM, Barry Warsaw wrote:
>
> > Another reason to oppose this is what I've heard quite often from people
> > regarding Python 2.7. I've been told that many folks are actually really
> > happy with using 2.7 precise
On Thu, Sep 26, 2013 at 9:52 AM, Eli Bendersky wrote:
> Hi All,
>
> Earlier this morning I had a slight tackle with a couple of the 3.4 bots
> (sorry everyone!). I fixed some problems in asdl.py -
> http://hg.python.org/cpython/rev/21d46e3ae60c - and used the 'with'
> statement. Some bots don't h
On Fri, Sep 27, 2013 at 5:16 PM, Zachary Ware
wrote:
> On Fri, Sep 27, 2013 at 3:29 PM, Donald Stufft wrote:
> >
>
> >
> > If it lives in the source tree how are you going to provent it from
> existing when someone installs on Linux? OSX? One of the BSDs?
>
> If someone is building their own Pyt
On Fri, Sep 27, 2013 at 6:33 PM, Guido van Rossum wrote:
> I've been looking at my progress with Tulip and the 3.4 release schedule
> (PEP 429) and it looks like I will have to do some kind of sprint to get it
> into the release in time for beta 1, which is planned for Nov 24. Ideally
> I'd get i
On Wed, Oct 2, 2013 at 2:58 PM, Stefan Behnel wrote:
> Hi,
>
> I'm looking back on a rather unpleasant experience that I recently had in
> this developer community. Actually, twice by now. Here's what I take from
> it:
>
> You should take responsibility for your commits.
>
> Sounds like a simple
On Tue, Oct 8, 2013 at 5:29 PM, Ethan Furman wrote:
> Greetings,
>
> Currently, inspect() is dependent on dir().
>
What's inspect()? I don't know of any global with that name and you are
obviously not talking about the module.
___
Python-Dev mailing li
On Thu, Oct 10, 2013 at 9:38 AM, Antoine Pitrou wrote:
> Le Thu, 10 Oct 2013 14:36:26 +0200,
> Dirkjan Ochtman a écrit :
>
> > On Thu, Oct 10, 2013 at 2:25 PM, Christian Heimes
> > wrote:
> > > Benchmark of 1000 times "python -c ''"
> > >
> > > Python 3.4dev with all my experimental patches:
>
On Sat, Oct 12, 2013 at 5:38 AM, Paul Moore wrote:
> On 12 October 2013 00:29, Nick Coghlan wrote:
> > There's no grand policy change or clarification needed here, it's just
> > another consequence of the fact that the import system isn't documented
> > properly in versions prior to 3.3.
>
> And
On Sat, Oct 12, 2013 at 1:19 PM, Christian Heimes wrote:
> Hi,
>
> I have written a interface to OpenSSL's PKCS5_PBKDF2_HMAC() function. It
> implements PKCS#5's password based key derivation function 2 with HMAC
> as pseudo-random function. It supports any digest that is supported by
> OpenSSL, e
On Sun, Oct 13, 2013 at 3:08 PM, Victor Stinner wrote:
> Le 13 oct. 2013 10:19, "Stefan Behnel" a écrit :
>
> > I agree. I find it much easier to read a plain and obvious
> >
> > try:
> >from _cmodule import *
> > except ImportError:
> >from _pymodule import *
> >
> > in a
, before 3.4a4, and let it bake in trunk a little before feature freeze
>> at beta 1 while I run around and finish the documentation.
>>
>>
>> You can review the existing code here:
>>
>> https://bitbucket.org/larry/python-clinic/
>>
>> (Yes, in this for
On Fri, Oct 18, 2013 at 4:10 AM, Paul Moore wrote:
> On 17 October 2013 23:40, Larry Hastings wrote:
> > For those interested parties: Guido just checked "asyncio", aka "Tulip",
> aka
> > "PEP 3156", in to trunk. I expect it to be part of Python 3.4.0a4,
> > hopefully to be released this weeken
importlib.machinery.FileFinder does a stat call to check if a path is a
file if the package check failed. Now I'm willing to bet that the check is
rather redundant as the file extension should be a dead give-away that
something in a directory is a file and not some non-file type. The import
would s
On Tue, 7 Jun 2016 at 14:38 Paul Sokolovsky wrote:
> Hello,
>
> On Tue, 7 Jun 2016 17:31:19 -0400
> Barry Warsaw wrote:
>
> > On Jun 07, 2016, at 01:28 PM, Ethan Furman wrote:
> >
> > >* Add ``bytes.iterbytes``, ``bytearray.iterbytes`` and
> > > ``memoryview.iterbytes`` alternative iterators
>
On Thu, 9 Jun 2016 at 14:56 Nick Coghlan wrote:
> On 8 June 2016 at 14:01, Neil Schemenauer wrote:
> > [I've posted something about this on python-ideas but since I now
> > have some basic working code, I think it is more than an idea.]
> >
> > I think the uptake of Python 3 is starting to accel
On Thu, 9 Jun 2016 at 16:08 Neil Schemenauer wrote:
> On 2016-06-09, Brett Cannon wrote:
> > On Thu, 9 Jun 2016 at 14:56 Nick Coghlan wrote:
> > > Once you switch to those now recommended more conservative migration
> > > tools, the tool suite you request already e
On Thu, 9 Jun 2016 at 19:53 Mark Lawrence via Python-Dev <
python-dev@python.org> wrote:
> On 10/06/2016 00:43, Brett Cannon wrote:
> >
> > That's not what I'm saying at all (nor what I think Nick is saying);
> > more tooling to ease the transition is always
On Fri, 10 Jun 2016 at 10:11 Steven D'Aprano wrote:
> On Fri, Jun 10, 2016 at 05:07:18PM +0200, Victor Stinner wrote:
> > I started to work on visualisation. IMHO it helps to understand the
> problem.
> >
> > Let's create a large dataset: 500 samples (100 processes x 5 samples):
> > ---
> > $ pyt
On Fri, 10 Jun 2016 at 12:20 Donald Stufft wrote:
>
> On Jun 10, 2016, at 3:05 PM, David Mertz wrote:
>
> OK. My understanding is that Guido ruled out introducing an
> os.getrandom() API in 3.5.2. But would you be happy if that interface is
> added to 3.6?
>
> It feels to me like the correct s
On Sat, 11 Jun 2016 at 08:05 Chi Hsuan Yen wrote:
> Hello all,
>
> Georg said in February that 3.2.7 is going to be released, and now it's
> June. Will it ever be released?
>
> pip [2], virtualenv [3] and setuptools [4] have all dropped Python 3.2
> support, and there's no new commits since 2016/
On Sat, 11 Jun 2016 at 11:31 Donald Stufft wrote:
> On Jun 11, 2016, at 1:39 PM, Guido van Rossum wrote:
>
> Is the feature detection desire about being able to write code that runs
> on older Python versions or for platforms that just don't have getrandom()?
>
> My assumption was that nobody wo
http://bugs.python.org/issue27288 covers updating the secrets module to use
getrandom().
http://bugs.python.org/issue27292 covers documenting the drawbacks of
os.urandom()
http://bugs.python.org/issue27293 covers documenting all of the issues
pointed out in this discussion.
Only issue I can thin
On Tue, 14 Jun 2016 at 13:30 Alan Franzoni wrote:
> Hello,
> I hope not to bother anyone with a somewhat trivial question, I was
> unable to get an answer from other channels.
>
> I was just checking out some docs on ABCs for a project of mine, where
> I need to do some type-related work. Those a
On Wed, 15 Jun 2016 at 09:48 Guido van Rossum wrote:
> These are really two separate proposals.
>
> I'm okay with checking the return value of calling obj.__fspath__; that's
> an error in the object anyways, and it doesn't matter much whether we do
> this or not (though when approving the PEP I c
gh where we've used os.fspath() to see where we can cut
out redundant type checks?
> --Guido (mobile)
> On Jun 15, 2016 11:29 AM, "Nick Coghlan" wrote:
>
>> On 15 June 2016 at 10:59, Brett Cannon wrote:
>> >
>> >
>> > On Wed, 15 Jun 2016
On Wed, 15 Jun 2016 at 12:12 Koos Zevenhoven wrote:
> >> if isinstance(filename, os.PathLike):
>
> By the way, regarding the line of code above, is there a convention
> regarding whether implementing some protocol/interface requires
> registering with (or inheriting from) the appropriate ABC
PEP 519 updated: https://hg.python.org/peps/rev/92feff129ee4
On Wed, 15 Jun 2016 at 11:44 Brett Cannon wrote:
> On Wed, 15 Jun 2016 at 11:39 Guido van Rossum wrote:
>
>> OK, so let's add a check on the return of __fspath__() and keep the check
>> on path-like or st
I have taken PEP 523 for this:
https://github.com/python/peps/blob/master/pep-0523.txt .
I'm waiting until Guido gets back from vacation, at which point I'll ask
for a pronouncement or assignment of a BDFL delegate.
On Fri, 3 Jun 2016 at 14:37 Brett Cannon wrote:
> For those of y
On Fri, 17 Jun 2016 at 18:13 Nick Coghlan wrote:
> On 16 June 2016 at 19:00, Kevin Ollivier
> wrote:
> > Hi Guido,
> >
> > From: on behalf of Guido van Rossum
> >
> > Reply-To:
> > Date: Thursday, June 16, 2016 at 5:27 PM
> > To: Kevin Ollivier
> > Cc: Python Dev
> > Subject: Re: [Python-De
On Sat, 18 Jun 2016 at 07:30 Cory Benfield wrote:
>
> > On 18 Jun 2016, at 04:06, Brett Cannon wrote:
> >
> > Do we need a security SIG? E.g. would people like Christian and Cory
> like to have a separate place to talk about the ssl stuff brought up at the
> language
Over on the "security SIG" thread, the point has been made that we seem to
be hitting some limits in communication (Steve Dower said written
communication, Guido said mailing lists/newsgroups). Based on the burnout
we are seeing from these centi-threads we need to try and come up with some
solution
But as
I said, I have not looked into the feasibility of this at all to know if
I'm remembering the weakref implementation details correctly.
>
> Finally, there are some error messages from pep2html.py:
> https://www.python.org/dev/peps/pep-0523/#copyright
>
All fixed in
https://gith
On Sun, 19 Jun 2016 at 21:01 Mark Shannon wrote:
>
>
> On 19/06/16 18:29, Brett Cannon wrote:
> >
> >
> > On Sat, 18 Jun 2016 at 21:49 Guido van Rossum > <mailto:gu...@python.org>> wrote:
> >
> > Hi Brett,
> >
> > I
On Sun, 19 Jun 2016 at 19:37 Guido van Rossum wrote:
> On Sun, Jun 19, 2016 at 6:29 PM, Brett Cannon wrote:
>
>>
>>
>> On Sat, 18 Jun 2016 at 21:49 Guido van Rossum wrote:
>>
>>> Hi Brett,
>>>
>>> I've got a few questions about th
On Mon, 20 Jun 2016 at 13:43 Christian Heimes wrote:
> On 2016-06-20 22:18, Guido van Rossum wrote:
> > On Mon, Jun 20, 2016 at 12:59 PM, Brett Cannon > <mailto:br...@python.org>> wrote:
> >
> > MRAB's response made me think of a possible approach
On Wed, 29 Jun 2016 at 10:41 Ethan Furman wrote:
> There is a several-month-old request to add aenum's [1] AutoNumberEnum
> to the stdlib [2].
>
> The requester and two of the three developers of Enum are in favor (the
> third hasn't chimed in yet).
>
> This new addition would enable the followin
[forking the conversation since the subject has shifted]
On Sun, 3 Jul 2016 at 09:50 Steve Dower wrote:
> Many of our users prefer stability (the sort who plan operating system
> updates years in advance), but generally I'm in favour of more frequent
> releases.
>
So there's our 18 month cadenc
On Sun, Jul 3, 2016, 13:43 Paul Moore wrote:
> On 3 July 2016 at 21:22, Brett Cannon wrote:
> > Topic 2
> > ===
> > Independent releases of the stdlib could be done, although if we break
> the
> > stdlib up into individual repos then it shifts the conversa
On Sun, Jul 3, 2016, 14:22 Paul Moore wrote:
> On 3 July 2016 at 22:04, Brett Cannon wrote:
> > This last bit is what I would advocate if we broke the stdlib out unless
> an
> > emergency patch release is warranted for a specific module (e.g. like
> > asyncio that
d it *quite* nice), but simply to observe that the
> Rust team might have useful info on upsides, downsides, and particular
> gotchas as Python considers changing its own release process.
>
> Regards,
> Chris Krycho
>
> On Jul 3, 2016, at 16:22, Brett Cannon wrote:
>
>
Once the GH migration occurs I think we will take a look at Homu (it's been
brought up previously).
On Sun, Jul 3, 2016, 17:35 Chris Krycho wrote:
> The bots Mozilla runs around both Rust and Servo should make a lot of this
> much lower overhead if they can be repurposed (as I believe several ot
1001 - 1100 of 3314 matches
Mail list logo
