On 18 October 2013 03:25, Glenn Linderman wrote:
> First, thanks for the education. What you wrote is extremely edifying about
> more than just context managers, and I really appreciate the visionary
> understanding you reported from BrisPy and further elucidated on, regarding
> the educational pa
First, thanks for the education. What you wrote is extremely edifying
about more than just context managers, and I really appreciate the
visionary understanding you reported from BrisPy and further elucidated
on, regarding the educational pattern of using things before you learn
how they work..
On 19 Oct 2013 03:24, "brett.cannon" wrote:
>
> http://hg.python.org/cpython/rev/11f2f4af1979
> changeset: 86444:11f2f4af1979
> user:Brett Cannon
> date:Fri Oct 18 13:24:13 2013 -0400
> summary:
> Issue #18810: Be optimistic with stat calls when seeing if a directory
> exists
On 19 Oct 2013 02:01, "brett.cannon" wrote:
>
> http://hg.python.org/cpython/rev/33844153cd02
> changeset: 86438:33844153cd02
> user:Brett Cannon
> date:Fri Oct 18 12:01:06 2013 -0400
> summary:
> Issue #18416: Fix various os calls in importlib.machinery.FileFinder
> now that
On 19 Oct 2013 03:57, "Charles-François Natali" wrote:
>
> Hi,
>
> I'm happy to see this move forward!
Speaking of which... Charles-François, would you be willing to act as
BDFL-Delegate for this PEP? This will be a very useful new analysis tool,
and between yourself and Victor it looks like you'
On 19 Oct 2013 02:56, "Brett Cannon" wrote:
>
> 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 fi
2013/10/18 Charles-François Natali :
> I'm happy to see this move forward!
Thanks for your reviews. I had some time in my train travel to improve
the implementation.
I removed the call to pthread_atfork(): tasks have been removed, it
now makes sense to keep tracemalloc enabled in the child proces
Thanks! That's probably fine for now -- it means the standard library
doesn't know where the root certificates are. We had a huge discussion
about this over on python-tulip:
https://groups.google.com/forum/#!topic/python-tulip/c_lqdFjPEbE
TL;DR: The stdlib openssl wrapper ought to know where each
On Fri, Oct 18, 2013 at 2:59 PM, Antoine Pitrou wrote:
> Is it one stat() call per successful import? Or one stat() call per
> sys.path entry?
It's one per finder (i.e. path entry) where a matching name is in the
directory (per the finder's cache). So it's a pretty uncommon case
with not much ov
On 18/10/2013 10:37pm, Guido van Rossum wrote:
Good sleuthing! Does the attached patch fix it?
(Off-topic: the code is pretty inconsistent about catching
BaseException. Maybe it shouldn't be caught at all?)
It fixes it in the sense of printing a sensible traceback;-)
$ PYTHONPATH='c:/Repos/tu
Good sleuthing! Does the attached patch fix it?
(Off-topic: the code is pretty inconsistent about catching BaseException.
Maybe it shouldn't be caught at all?)
On Fri, Oct 18, 2013 at 2:04 PM, Richard Oudkerk wrote:
> On 18/10/2013 9:19pm, Guido van Rossum wrote:
>
>> Maybe the dummy socket re
On 19 October 2013 03:53, Brett Cannon wrote:
> 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
On 18/10/2013 9:19pm, Guido van Rossum wrote:
Maybe the dummy socket returned by wrap_socket() is not acceptable for
select?
An error
SSLError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify
failed (_ssl.c:553)')
is being raised in _on_handshake(). This seems to result in the s
On Fri, 18 Oct 2013 12:53:55 -0400
Brett Cannon wrote:
> 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 di
Maybe the dummy socket returned by wrap_socket() is not acceptable for
select?
--Guido van Rossum (sent from Android phone)
On Oct 18, 2013 11:26 AM, "Richard Oudkerk" wrote:
> On 18/10/2013 6:57pm, Guido van Rossum wrote:
>
>> Thanks! Those are all expected (though contributions are always welc
18.10.13 21:04, Brett Cannon написав(ла):
That was it, so Antoine and Zach were right about the location. Should
be fixed now.
Thank you Brett.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Uns
On 18/10/2013 6:57pm, Guido van Rossum wrote:
Thanks! Those are all expected (though contributions are always welcome
-- not looking at you specifically :-).
Does examples/fetch3.py work for you with an https URL? (Try
http://dropbox.com, i.e. without 's' -- you get two redirects to https
URLs.
On Fri, Oct 18, 2013 at 1:53 PM, Brett Cannon wrote:
>
>
>
> On Fri, Oct 18, 2013 at 1:51 PM, Brett Cannon wrote:
>
>>
>>
>> On Fri, Oct 18, 2013 at 1:34 PM, Zachary Ware <
>> zachary.ware+py...@gmail.com> wrote:
>>
>>> On Fri, Oct 18, 2013 at 12:30 PM, Antoine Pitrou
>>> wrote:
>>> >
>>> > Is
Thanks! Those are all expected (though contributions are always welcome --
not looking at you specifically :-).
Does examples/fetch3.py work for you with an https URL? (Try
http://dropbox.com, i.e. without 's' -- you get two redirects to https
URLs. :-)
On Fri, Oct 18, 2013 at 10:36 AM, Richard
Hi,
I'm happy to see this move forward!
> API
> ===
>
> Main Functions
> --
>
> ``clear_traces()`` function:
>
> Clear traces and statistics on Python memory allocations, and reset
> the ``get_traced_memory()`` counter.
That's nitpicking, but how about just ``reset()`` (I'm p
On Fri, Oct 18, 2013 at 1:51 PM, Brett Cannon wrote:
>
>
> On Fri, Oct 18, 2013 at 1:34 PM, Zachary Ware <
> zachary.ware+py...@gmail.com> wrote:
>
>> On Fri, Oct 18, 2013 at 12:30 PM, Antoine Pitrou
>> wrote:
>> >
>> > Is anyone looking into those leaks?
>> > I suspect they might have to do wit
On Fri, Oct 18, 2013 at 1:34 PM, Zachary Ware
wrote:
> On Fri, Oct 18, 2013 at 12:30 PM, Antoine Pitrou
> wrote:
> >
> > Is anyone looking into those leaks?
> > I suspect they might have to do with Serhiy's latest re changes in
> > add40e9f7cbe.
> > (just a barely educated guess, though)
>
> I ha
tl;dr:
2.7 -> 3.3 = 1.92x slower
2.7 -> 3.4 = 1.36x slower
3.3 -> 3.4 = 1.40x faster
IOW the work people have been putting in to speed up interpreter startup
are definitely paying off.
> ./perf.py -b normal_startup,startup_nosite ../cpython/py3.3/python.exe
../cpython/default/python.exe
Running
On 18/10/2013 6:15pm, Guido van Rossum wrote:
Thanks! There are some new changes (I fixed a race with sockets closing)
and I hope to land flow control (finally) later today.
Do you know what those skips are? I suspect they might be due to ssl not
working for you either. :-(
Lack of support for
On Fri, Oct 18, 2013 at 12:30 PM, Antoine Pitrou wrote:
>
> Is anyone looking into those leaks?
> I suspect they might have to do with Serhiy's latest re changes in
> add40e9f7cbe.
> (just a barely educated guess, though)
I have confirmed that and was working towards getting my findings
posted wh
Is anyone looking into those leaks?
I suspect they might have to do with Serhiy's latest re changes in
add40e9f7cbe.
(just a barely educated guess, though)
Regards
Antoine.
On Fri, 18 Oct 2013 09:31:49 +0200
solip...@pitrou.net wrote:
> results for 30f33e6a04c1 on branch "default"
> -
Thanks! There are some new changes (I fixed a race with sockets closing)
and I hope to land flow control (finally) later today.
Do you know what those skips are? I suspect they might be due to ssl not
working for you either. :-(
On Fri, Oct 18, 2013 at 10:04 AM, Richard Oudkerk wrote:
> On 18/1
On 18/10/2013 5:31pm, Guido van Rossum wrote:
I'm working from home today and my Windows laptop is in the office, so I
won't be able to test my latest Tulip changes on Windows (I just renamed
pause to pause_reading, and hope to commit pause_reading later today).
Is anyone luckier?
$ hg id
97f6f
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
I'm working from home today and my Windows laptop is in the office, so I
won't be able to test my latest Tulip changes on Windows (I just renamed
pause to pause_reading, and hope to commit pause_reading later today). Is
anyone luckier?
Also, reading through the Windows OpenSSL setup in PCbuild/rea
ACTIVITY SUMMARY (2013-10-11 - 2013-10-18)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open4184 (-56)
closed 26872 (+115)
total 31056 (+59)
Open issues wi
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
This looks really nice to me, and splitting it so the core
functionality is in the standard library and there's a separate higher
level tool on PyPI (allowing faster iteration on the analysis
features) is a fine idea.
Cheers,
Nick.
___
Python-Dev mailing
Hi,
I plan to push the new tracemalloc module this week-end, before the
next (and last) alpha version, except if someone complains :-) I
prefer to have one month before the first beta to have more time to
test the module. So if a major issue is raised, we may remove the
tracemalloc module before t
Le Fri, 18 Oct 2013 20:16:03 +1000,
Nick Coghlan a écrit :
> >
> > Also, shouldn't it be excluded from the stable/limited API?
>
> Since it didn't expose any struct layouts, I just followed the
> precedent set by the other PySet_* APIs on that front. Moving it
> would be fine, too, though, since
On 18 Oct 2013 15:20, "Georg Brandl" wrote:
>
> Am 17.10.2013 17:36, schrieb Antoine Pitrou:
> > On Thu, 17 Oct 2013 15:22:03 +0200 (CEST)
> > nick.coghlan wrote:
> >>
> >> +.. c:function:: int Py_SetStandardStreamEncoding(char *encoding, char
*errors)
> >> +
> >> + .. index::
> >> + singl
On 18 October 2013 09:56, Terry Reedy wrote:
> I believe once every 24 hours. The current page is dated Oct 17 (at bottom).
> It is now Oct 18 most everywhere.
Thanks, I didn't know there was a generated date at the bottom. Useful
to know for the future! I'll wait for the update, cheers.
Paul
___
On 10/18/2013 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 weekend.
Cool! How often do t
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 weekend.
Cool! How often do the online docs get built? There's nothi
39 matches
Mail list logo
