On Tue, Aug 7, 2018 at 11:14 PM, Ken Hilton wrote:
> This mostly springs off of a comment I saw in some thread.
>
> The point of a with statement is that it ensures that some resource will be
> disposed of, yes? For example, this:
>
> with open(filename) as f:
> contents = f.read()
>
>
On Mon, Aug 20, 2018 at 12:19 AM, Simon De Greve wrote:
> Hello everyone,
>
> I'm quite new working with asyncio and thus maybe missing some things about
> it, but wouldn't it be quite easier to have some iterables to support async
> for loops "natively", since asyncio is now part of the Stdlib?
>
On Mon, Aug 20, 2018 at 12:34 AM, Simon De Greve wrote:
> Do you mean that for loops inside an "async def" statements are always
> executed as 'async for' loops? That's what I wanted to acheive by writing
> the AsyncDict class (c.f. the CodeReview link).
The only difference between an 'async for'
On Thu, Sep 13, 2018 at 9:13 AM, Mark E. Haase wrote:
> On Thu, Sep 13, 2018 at 10:49 AM Rhodri James wrote:
>
>> More importantly, this whole idea of banning and/or changing terminology
>> is psychologically and sociologically wrong-headed. The moment you say "You
>> may not use that word" you
On Fri, Sep 28, 2018 at 11:31 PM, Steve Barnes wrote:
> One specific use case that springs to mind would be for Libraries such
> as Pandas to return iNaN for entries that are not numbers in a column
> that it has been told to treat as integers.
Pandas doesn't use Python objects to store integers,
On Tue, Oct 2, 2018 at 8:44 PM, David Teresi wrote:
> print(f'{value!d}') is a lot of symbols and boilerplate to type out just
for
> a debugging statement that will be deleted later. Especially now that
> breakpoint() exists, I can't really see myself using this.
>
> I also don't see the use case
On Wed, Oct 3, 2018, 03:55 Eric V. Smith wrote:
>
> On 10/3/2018 1:40 AM, Nathaniel Smith wrote:
> > I think the way I'd do it would be:
> >
> > Step 1: Take the current "lnotab" that lets us map bytecode offsets ->
> > line numbers, and exte
On Wed, Oct 3, 2018 at 10:48 AM, Chris Angelico wrote:
> On Thu, Oct 4, 2018 at 2:30 AM Anders Hovmöller wrote:
>>
>> Nothing is a keyword in that example or in my example. My suggestion is that
>> we could do:
>>
>> my_func(=big_array[5:20])
>>
>> And it would be compile time transformed into
>
On Sat, Oct 6, 2018 at 12:22 AM, Ram Rachum wrote:
> I'd like to use the re module to parse a long text file, 1GB in size. I wish
> that the re module could parse a stream, so I wouldn't have to load the
> whole thing into memory. I'd like to iterate over matches from the stream
> without keeping
On Sat, Oct 6, 2018 at 2:04 PM, Chris Angelico wrote:
> On Sun, Oct 7, 2018 at 8:01 AM Nathaniel Smith wrote:
>>
>> On Sat, Oct 6, 2018 at 12:22 AM, Ram Rachum wrote:
>> > I'd like to use the re module to parse a long text file, 1GB in size. I
>> > wish
On Sat, Oct 6, 2018, 18:40 Steven D'Aprano wrote:
> The message I take from this is:
>
> - regex engines certainly can be written to support streaming data;
> - but few of them are;
> - and it is exceedingly unlikely to be able to easily (or at all)
> retro-fit that support to Python's existing
On Sun, Oct 7, 2018 at 5:09 PM, Terry Reedy wrote:
> On 10/6/2018 5:00 PM, Nathaniel Smith wrote:
>>
>> On Sat, Oct 6, 2018 at 12:22 AM, Ram Rachum wrote:
>>>
>>> I'd like to use the re module to parse a long text file, 1GB in size. I
>>> wish
&g
On Sun, Oct 7, 2018 at 5:54 PM, Nathaniel Smith wrote:
> Are you imagining something roughly like this? (Ignoring chunk
> boundary handling for the moment.)
>
> def find_double_line_end(buf):
> start = 0
> while True:
> next_idx = buf.index(b"\n", s
On Mon, Oct 8, 2018 at 2:55 AM, Steven D'Aprano wrote:
>
> On Mon, Oct 08, 2018 at 09:10:40AM +0200, Jimmy Girardet wrote:
>> Each tool which wants to use pyproject.toml has to add a toml lib as a
>> conditional or hard dependency.
>>
>> Since toml is now the standard configuration file format,
>
Hi Vladimir,
It's great to see people revisiting these old stdlib tools. Closure
tracking is definitely a big point of awkwardness for Queues. In Trio we
started with a straight copy of threading.Queue, and this turned out to be
a major friction point for users. We just deprecated our version of Q
On Sun, Oct 21, 2018, 16:48 MRAB wrote:
> On 2018-10-21 22:30, Antoine Pitrou wrote:
> > On Sun, 21 Oct 2018 19:58:05 +0200
> > Vladimir Filipović
> > wrote:
> >>
> >> To anticipate a couple more possible questions:
> >>
> >> - What would this proposal do about multiple producers/consumers
> >>
On Sun, Oct 21, 2018 at 8:31 PM, Guido van Rossum wrote:
> On Sun, Oct 21, 2018 at 6:08 PM Nathaniel Smith wrote:
>> I'm not sure if this is an issue the way Queue is used in practice, but in
>> general you have to be careful with this kind of circular flow because if
>&g
On Wed, Oct 24, 2018 at 11:23 AM, Marko Ristin-Kaufmann
wrote:
> I imagine that you conceive contracts purely as an approach to a testing to
> be applied to a single project. I'm not talking about that. I'm talking
> about two packages on pypi, both specifying contracts, each developed by a
> sepa
On Thu, Oct 25, 2018, 14:44 Marko Ristin-Kaufmann
wrote:
>
> Nathaniel Smith wrote:
>
>> In your position, I wouldn't be talking to the core devs; I'd be
>> writing blog posts to proselytize the advantages of contracts, working
>> with popular projects
The WSGI PEP is a bit of a funny thing, since it's a PEP that doesn't
really involve the language or stdlib. (I guess there's wsgiref, but I
don't think it being in the stdlib actually affects much these days.)
What are you hoping to accomplish by making ASGI a PEP?
-n
On Sat, Oct 27, 2018 at 4:
On Fri, Nov 9, 2018 at 4:32 PM, danish bluecheese
wrote:
> you are right on the lines you mentioned. Those are all working if i run it
> as a module which i do every time.
> This is somewhat unpleasant to me, especially while developing something and
> trying to test it quickly.
> I just want to b
On Mon, Nov 19, 2018 at 6:09 PM Steven D'Aprano wrote:
>
> On Mon, Nov 19, 2018 at 05:09:25PM -0800, danish bluecheese wrote:
> > I think it is kind of useless effort. If somebody using range() then
> > probably knows about it.
>
> For experienced users, sure, but this is an enhancement to help
>
For this specific purpose, md5 is just as good as a proper hash. But all
else being equal, it would still be better to use a proper hash, just so
people don't have to go through the whole security analysis to check that.
Of course all else isn't equal: switching from md5 to sha-whatever would
requ
On Fri, Dec 7, 2018 at 3:38 PM Steven D'Aprano wrote:
> On Fri, Dec 07, 2018 at 01:25:19PM -0800, Nathaniel Smith wrote:
>
> > For this specific purpose, md5 is just as good as a proper hash. But all
> > else being equal, it would still be better to use a proper hash, j
If you want this style of concurrency, you don't need to write a PEP,
just 'pip install gevent' :-)
But unfortunately you're years too late to argue for making asyncio
work this way. This was discussed extensively at the time, and the
decision to use special syntax was made intentionally, and afte
On Wed, Dec 26, 2018, 02:19 Andrew Svetlov
> Also I'm thinking about type annotations in typeshed.
> Now the type is Union[array[int], bytes, bytearray, memoryview]
> Should it be Union[io.BinaryIO, array[int], bytes, bytearray, memoryview] ?
>
Yeah, trying to support both buffers and file-like o
On Sat, Jan 5, 2019 at 9:13 PM Moon丶sun wrote:
>
> Thanks for your reply.
> But the answer is not I except, I will show you some examples to explain what
> result I except:
>
> @contextmanager
> def cm():
> print('open file')
> yield
> print('close file')
> with cm():
> 1/0
>
> If
On Sun, Jan 6, 2019 at 11:06 PM Steven D'Aprano wrote:
> I'm not wedded to the idea that the default ought to be the current
> behaviour. If there is a strong argument for one of the others, I'm
> listening.
"Errors should never pass silently"? Silently returning nonsensical
results is hard to de
The first concern that comes to my mind is... When I see:
with:
...
except:
...
Is that a shorthand for
try:
with:
...
except:
...
or for
with:
try:
...
except:
...
? Both are plausible, and it makes a big difference, because 'with' already
has
On Mon, Mar 4, 2019 at 11:41 PM INADA Naoki wrote:
> Then, I propose `dict.merge` method. It is outer-place version
> of `dict.update`, but accepts multiple dicts. (dict.update()
> can be updated to accept multiple dicts, but it's not out of scope).
>
> * d = d1.merge(d2) # d = d1.copy(); d.upd
Defining a single polymorphic function is easy at the library level.
For example, with asyncio:
def maybe_async(fn):
@functools.wraps(fn)
def wrapper(*args, **kwargs):
coro = fn(*args, **kwargs)
if asyncio.get_running_loop() is not None:
return coro
On Wed, Mar 6, 2019 at 4:37 PM pylang wrote:
>> def maybe_async(fn):
>> @functools.wraps(fn)
>> def wrapper(*args, **kwargs):
>> coro = fn(*args, **kwargs)
>> if asyncio.get_running_loop() is not None:
>> return coro
>> else:
>> return await
On Wed, Mar 6, 2019 at 12:13 PM Matěj Cepl wrote:
>
> Hi,
>
> I am a lead maintainer of Python packages in OpenSUSE and I can
> see the pattern of many packagers adding blindly
>
> python setup.py test
>
> to %check section of our SPEC file. The problem is that if the
> package doesn't use uni
These kinds of low-level synchronization primitives are notoriously
tricky, yeah, and I'm all in favor of having better higher-level
tools. But I'm not sure that AutoResetEvent adds enough to be worth
it.
AFAICT, you can get this behavior with an Event just fine – using your
pseudocode:
def sende
On Tue, Mar 26, 2019, 09:50 Richard Whitehead
wrote:
> Nathaniel,
>
> Thanks very much for taking the time to comment.
>
> Clearing the event after waiting for it will introduce a race condition:
> if
> the sender has gone around its loop again and set the semaphore after we
> have woken but befo
On Thu, Mar 28, 2019 at 4:52 PM Steven D'Aprano wrote:
> On Thu, Mar 28, 2019 at 03:25:34PM -, Richard Whitehead wrote:
> > Chris,
> >
> > As a new member to this list, I can tell you that searching for relevant old
> > content was effectively impossible, so I'm all for some way of doing that.
On Sun, Mar 31, 2019 at 9:17 PM Nam Nguyen wrote:
> Installing a package out of stdlib does not solve the problem that motivated
> this thread. The libraries included in the stdlib can't use those parsers.
Can you be more specific about exactly which code in the stdlib you
think should be rewrit
On Thu, Apr 4, 2019 at 12:48 AM Greg Ewing wrote:
>
> The check_output() function of the subprocess module raises an
> exception if the process returns a non-zero exit status. This is
> inconvenient for commands such as grep that use the return
> status to indicate something other than success or
On Thu, Apr 4, 2019 at 1:59 AM Greg Ewing wrote:
>
> Nathaniel Smith wrote:
> > On Thu, Apr 4, 2019 at 12:48 AM Greg Ewing
> > wrote:
> >>output(args) --> (status, output)
> >
> > Isn't this already available as: run(args, stdout=PIPE)?
>
&
On Sun, Apr 7, 2019 at 7:37 PM Steven D'Aprano wrote:
> There are quite a few important algorithms which require lists to be
> sorted. For example, the bisect module, and for statistics median and
> other quantiles.
But this flag doesn't affect those modules, right? 'bisect' already
requires the
On Mon, Apr 8, 2019, 02:09 Steven D'Aprano wrote:
> On Sun, Apr 07, 2019 at 08:26:24PM -0700, Nathaniel Smith wrote:
> > On Sun, Apr 7, 2019 at 7:37 PM Steven D'Aprano
> wrote:
> > > There are quite a few important algorithms which require lists to be
> &
I don't think it's possible to make this work reliably. In particular, it's
an important feature of python that you can make wrappers that pass through
arguments and are equivalent to the original function:
def original(a=0):
...
def wrapper(*args, **kwargs):
return original(*args, **kwar
On Wed, Oct 5, 2016 at 1:28 PM, Rene Nejsum wrote:
> When I first read about the async idea, I initially expected that it would be
> some stackless like additions to Python. My wish for Python was an addition
> to the language the allowed an easy an elegant concurrent model on the
> language le
On Thu, Oct 6, 2016 at 12:45 AM, Greg Ewing wrote:
> Nathaniel Smith wrote:
>>
>> It wasn't that we created these keywords to solve some
>> implementation problem and then inflicted them on users.
>
>
> I disagree -- looking at the history of how we
> end
On Thu, Oct 6, 2016 at 4:12 PM, Greg Ewing wrote:
> Nathaniel Smith wrote:
>>
>> The core distinguishing feature between
>> async/await and gevent is the visibility of suspension points, so it
>> might as well be the case that async/await is designed for exactly
>&
On Mon, Oct 10, 2016 at 2:59 AM, Martin Teichmann
wrote:
> This is why I got my idea to flag such calls. Unfortunately, I
> realized that it is nearly impossible to tell whether a read call is
> blocking or not. We would need to know whether the file descriptor we
> read from was created as non-bl
On Wed, Oct 12, 2016 at 2:19 PM, Elliot Gorokhovsky
wrote:
[...]
> So that was the motivation for all this. Actually, if I wrote this for
> python 2, I might be able to get even better numbers (at least for strings),
> since we can't use strcmp in python 3. (Actually, I've heard UTF-8 strings
> ar
The comparison methods on Python's str are codepoint-by-codepoint.
A neat fact about UTF-8 is that bytewise comparisons on UTF-8 are
equivalent to doing codepoint comparisons.
But this isn't relevant to Python's str, because Python's str never uses UTF-8.
-n
On Wed, Oct 12, 2016 at 2:45 PM, Ellio
On Wed, Oct 12, 2016 at 3:34 PM, Alexander Belopolsky
wrote:
>
> On Wed, Oct 12, 2016 at 6:14 PM, Elliot Gorokhovsky
> wrote:
>>
>> so then Latin1 strings are memcmp-able, and others are not.
>
>
> No. Strings of the same kind are "memcmp-able" regardless of their kind.
I don't think this is tr
On Fri, Oct 14, 2016 at 9:09 AM, wrote:
> For all intents and purposes other than debugging C (for cpython, rpython
> for pypy, java for jython, .NET for IronPython... you get the idea), the
> extra details are unnecessary to debug most problems. Most of the time it
> is sufficient to know what
The problem is that if your goal is to make a practical proposal, it's
not enough to look at Python-the-language. You're absolutely right,
AFAICT there's nothing stopping someone from making a nice
implementation of Python-the-language that has erlang-style cheap
shared-nothing threads with some ef
Hi all,
I'd like to propose that Python's iterator protocol be enhanced to add
a first-class notion of completion / cleanup.
This is mostly motivated by thinking about the issues around async
generators and cleanup. Unfortunately even though PEP 525 was accepted
I found myself unable to stop pond
On Wed, Oct 19, 2016 at 10:08 AM, Neil Girdhar wrote:
>
>
> On Wed, Oct 19, 2016 at 11:08 AM Todd wrote:
>>
>> On Wed, Oct 19, 2016 at 3:38 AM, Neil Girdhar
>> wrote:
>>>
>>> This is a very interesting proposal. I just wanted to share something I
>>> found in my quick search:
>>>
>>>
>>> http:/
On Wed, Oct 19, 2016 at 11:38 AM, Paul Moore wrote:
> On 19 October 2016 at 19:13, Chris Angelico wrote:
>> Now it *won't* correctly call the end-of-iteration function, because
>> there's no 'for' loop. This is going to either (a) require that EVERY
>> consumer of an iterator follow this new prot
On Wed, Oct 19, 2016 at 12:21 PM, Nathaniel Smith wrote:
> On Wed, Oct 19, 2016 at 11:38 AM, Paul Moore wrote:
>> On 19 October 2016 at 19:13, Chris Angelico wrote:
>>> Now it *won't* correctly call the end-of-iteration function, because
>>> there's no &
Hi Yury,
Thanks for the detailed comments! Replies inline below.
On Wed, Oct 19, 2016 at 8:51 AM, Yury Selivanov wrote:
> I'm -1 on the idea. Here's why:
>
>
> 1. Python is a very dynamic language with GC and that is one of its
> fundamental properties. This proposal might make GC of iterators
On Wed, Oct 19, 2016 at 1:33 PM, Yury Selivanov wrote:
> On 2016-10-19 3:33 PM, Nathaniel Smith wrote:
>
>>>>>>> lst = [1,2,3,4]
>>>>>>> >>>>>it = iter(lst)
>>>>>>> >>>>>for i in it:
>>>&
On Wed, Oct 19, 2016 at 11:13 AM, Chris Angelico wrote:
> On Thu, Oct 20, 2016 at 3:38 AM, Random832 wrote:
>> On Wed, Oct 19, 2016, at 11:51, Yury Selivanov wrote:
>>> I'm -1 on the idea. Here's why:
>>>
>>>
>>> 1. Python is a very dynamic language with GC and that is one of its
>>> fundamental
On Wed, Oct 19, 2016 at 3:07 PM, Paul Moore wrote:
> On 19 October 2016 at 20:21, Nathaniel Smith wrote:
>> On Wed, Oct 19, 2016 at 11:38 AM, Paul Moore wrote:
>>> On 19 October 2016 at 19:13, Chris Angelico wrote:
>>>> Now it *won't* correctly call the
On Wed, Oct 19, 2016 at 7:07 PM, Terry Reedy wrote:
> On 10/19/2016 12:38 AM, Nathaniel Smith wrote:
>
>> I'd like to propose that Python's iterator protocol be enhanced to add
>> a first-class notion of completion / cleanup.
>
>
> With respect the the standa
On Fri, Oct 21, 2016 at 3:48 PM, Amit Green wrote:
> NOTE: This is my first post to this mailing list, I'm not really sure
> how to post a message, so I'm attempting a reply-all.
>
> I like Nathaniel's idea for __iterclose__.
>
> I suggest the following changes to deal with a few of the comp
On Fri, Oct 21, 2016 at 3:29 AM, Steven D'Aprano wrote:
> As for the amount of good, this proposal originally came from PyPy.
Just to be clear, I'm not a PyPy dev, and the PyPy devs' contribution
here was mostly to look over a draft I circulated and to agree that it
seemed like something that'd b
On Tue, Oct 25, 2016 at 6:58 AM, Chris Angelico wrote:
> On Wed, Oct 26, 2016 at 12:20 AM, Michel Desmoulin
> wrote:
>> list, set and tuple less not as good:
>>
>> >>> tuple(foo)
>>
>> TypeError: 'int' object is not iterable
>>
>> No raiser, no value given. It's hard to find out what's th
On Tue, Oct 25, 2016 at 6:20 AM, Michel Desmoulin
wrote:
> Some things deserve a big explanation to solve the problem. It would be nice
> to add a link to official tutorial in the documentation.
>
> E.G, encoding is a big one:
>
>In [8]: b'é' + 'é'
> File "", line 1
>b'é' + 'é'
>
On Sat, Oct 22, 2016 at 9:02 AM, Nick Coghlan wrote:
> On 20 October 2016 at 07:02, Nathaniel Smith wrote:
>> The first change is to replace the outer for loop with a while/pop
>> loop, so that if an exception occurs we'll know which iterables remain
>> to be
x it within the function-scoping framework :-(
-n
On Tue, Oct 25, 2016 at 3:25 PM, Nathaniel Smith wrote:
> On Sat, Oct 22, 2016 at 9:02 AM, Nick Coghlan wrote:
>> On 20 October 2016 at 07:02, Nathaniel Smith wrote:
>>> The first change is to replace the outer for loop with a w
On Tue, Oct 25, 2016 at 2:55 PM, Chris Barker wrote:
>
>
>> But that's something of a solved problem. IPython offers a rich
>> interactive environment, for people who find the limitations of the
>> standard interactive prompt frustrating. Would it be worth the
>> standard Python documentation prom
On Wed, Oct 26, 2016 at 3:16 PM, Cody Piersall wrote:
> On Wed, Oct 26, 2016 at 4:48 PM, Paul Moore wrote:
>> Good point. We could, of course, detect when stdin is non-interactive,
>> but at that point the code is starting to get unreasonably complex, as
>> well as having way too many special cas
On Sun, Nov 6, 2016 at 5:06 AM, Eric V. Smith wrote:
> Creating a new thread, instead of hijacking the PEP 532 discussion.
>
> From PEP 532:
>
>> Abstract
>>
>>
>> Inspired by PEP 335, PEP 505, PEP 531, and the related discussions, this
>> PEP
>> proposes the addition of a new protocol-dr
On Sun, Nov 6, 2016 at 9:08 PM, C Anthony Risinger wrote:
> On Nov 6, 2016 7:32 PM, "Nathaniel Smith" wrote:
>>
>> [...]
>>
>> Some other use cases:
>>
>> Log some complicated object, but only pay the cost of stringifying the
>> object
On Nov 12, 2016 5:46 PM, "David Mertz" wrote:
>
> If we *do* want the name 'slice' as the spelling for the thing that can
either be called or indexed to create a slice object, we could probably use
some boilerplate like this:
>
>> In [1]: class Slice:
>>...: def __init__(self):
>>...:
On Nov 28, 2016 8:38 AM, "Guido van Rossum" wrote:
>
> Overall I think this is a good idea. I have one hit:
>
> It seems that there are two possible strategies for searching the
.missing.py file:
>
> 1. (Currently in the PEP) search it at the same time as the .py file when
walking along sys.path.
On Mon, Nov 28, 2016 at 5:28 AM, Tomas Orsava wrote:
[...]
> Specification
> =
>
> When, for any reason, a standard library module is not to be included with
> the
> rest, a file with its name and the extension ``.missing.py`` shall be
> created
> and placed in the directory the module
On Tue, Nov 29, 2016 at 1:05 AM, Victor Stinner
wrote:
> Hi,
>
> Python is optimized for performance. Formatting an error message has a
> cost on performances.
Sure, but we have to look at this on a case-by-case basis. Is there
really important code out there that's generating NameErrors or
Synta
On Nov 29, 2016 9:43 AM, "Brett Cannon" wrote:
>
>
>
> On Tue, 29 Nov 2016 at 02:39 Nathaniel Smith wrote:
>>
>> On Tue, Nov 29, 2016 at 1:05 AM, Victor Stinner
>> wrote:
>> > Hi,
>> >
>> > Python is optimized for perfo
On Dec 28, 2016 12:44, "Brett Cannon" wrote:
My quick on-vacation response is that attaching more objects to exceptions
is typically viewed as dangerous as it can lead to those objects being kept
alive longer than expected (see the discussions about richer error messages
to see that worry come ou
On Fri, Dec 30, 2016 at 9:29 AM, wrote:
> Updating the docs sounds like the more important change for now, given 3.7+.
> But before the docs make an official recommendation for that recipe, were
> the analyses that Steve and I did sufficient to confirm that its hash
> distribution and performance
I haven't had a chance to use it myself yet, but I've heard good things
about
https://construct.readthedocs.io/en/latest/
It's certainly far more comprehensive than struct for this and other
problems.
As usual, there's some tension between adding stuff to the stdlib versus
using more specialized
On Jan 20, 2017 09:00, "Paul Moore" wrote:
On 20 January 2017 at 16:51, Elizabeth Myers
wrote:
> Should I write up a PEP about this? I am not sure if it's justified or
> not. It's 3 changes (calcsize and two format specifiers), but it might
> be useful to codify it.
It feels a bit minor to need
On Jan 20, 2017 12:48 PM, "Elizabeth Myers"
wrote:
On 20/01/17 10:59, Paul Moore wrote:
> On 20 January 2017 at 16:51, Elizabeth Myers
wrote:
>> Should I write up a PEP about this? I am not sure if it's justified or
>> not. It's 3 changes (calcsize and two format specifiers), but it might
>> be
On Fri, Jan 20, 2017 at 3:37 PM, Elizabeth Myers
wrote:
[...]
>> Some of the responses on the bug are discouraging... mostly seems to
>> boil down to people just not wanting to expand the struct module or
>> discourage its use. Everyone is a critic. I didn't know adding two
>> format specifiers wa
On Fri, Jan 20, 2017 at 7:39 PM, Nathaniel Smith wrote:
> [...]
> Some of these strategies that you might find helpful (or not):
Oh right, and of course just after I hit send I realized I forgot one
of my favorites!
- come up with a real chunk of code from a real project that would
benefi
On Thu, Jan 26, 2017 at 2:32 PM, M.-A. Lemburg wrote:
> On 26.01.2017 23:09, Random832 wrote:
>> On Thu, Jan 26, 2017, at 11:21, Paul Moore wrote:
>>> On a similar note, I always get caught out by the fact that the
>>> Windows default download is the 32-bit version. Are we not yet at a
>>> point w
On Thu, Jan 26, 2017 at 6:46 PM, Matthias Bussonnier
wrote:
> On Thu, Jan 26, 2017 at 5:23 PM, Nathaniel Smith wrote:
>
>> It's also relatively common to need a 64-bit Python, e.g. if running
>> programs that need more than 4 GiB of address space. (Data analysts
>&g
On Fri, Jan 27, 2017 at 1:32 AM, Stephan Houben wrote:
> Hi all,
>
> FWIW, I got the following statement from here:
>
> https://github.com/numpy/numpy/wiki/Numerical-software-on-Windows
>
> "Standard numpy and scipy binary releases on Windows use pre-compiled ATLAS
> libraries and are 32-bit only
On Fri, Feb 17, 2017 at 2:22 AM, Stephan Houben wrote:
> Proposal: Light-weight call-by-name syntax in Python
>
> The following syntax
> a : b
> is to be interpreted as:
> a(lambda: b)
>
> Effectively, this gives a "light-weight macro system" to Python,
> since it allows with little
On Thu, Feb 16, 2017 at 9:24 PM, Joseph Hackman wrote:
> Howdy All!
>
> This suggestion is inspired by the question on "Efficient debug logging".
>
> I propose a keyword to mark an expression for delayed/lazy execution, for
> the purposes of standardizing such behavior across the language.
>
> The
On Fri, Feb 17, 2017 at 2:46 AM, Stephan Houben wrote:
> Hi Nathaniel,
>
>
> 2017-02-17 11:28 GMT+01:00 Nathaniel Smith :
>>
>> Note that this is definitely a different proposal from the original,
>> since the original proposer's goal was to be able to us
On Fri, Feb 17, 2017 at 9:34 PM, David Mertz wrote:
> On Fri, Feb 17, 2017 at 6:20 PM, Nathaniel Smith wrote:
>>
>> value = delayed: some_dict.get("whatever")
>> if value is None:
>> ...
>>
>> I.e., the question is, how does 'is&#x
On Feb 24, 2017 5:29 PM, "David Mertz" wrote:
Marc-André slightly misspelled the recent-ish addition of math.isclose(),
but I agree that it is absolutely where a "nextafter" belongs.
The function signature is already relatively complex to cover several
different but related use cases. I.e.:
On Sun, Apr 2, 2017 at 4:08 PM, Terry Reedy wrote:
> Both are subclasses of OSError but mean different things. TimeoutError
> means that something in 'your system' did not respond. Socket.timeout means
> that a foreign system did not respond. (I am leaving out a local socket
> connection.) The
On Mon, Apr 24, 2017 at 6:08 PM, Erik wrote:
> Hi. I suspect that this may have been discussed to death at some point in
> the past, but I've done some searching and I didn't come up with much.
> Apologies if I'm rehashing an old argument ;)
>
> I often find myself writing __init__ methods of the
On Tue, Apr 25, 2017 at 3:30 PM, Erik wrote:
> On 25/04/17 23:05, Paul Moore wrote:
>>
>> 1. Writing out the assignments "longhand" is an unacceptable burden.
>
>
> There are reasons why augmented assignment was implemented. One of them was
> to make the code easier to read:
>
> foil = foil + 1
Hi all,
Currently, given a frame object (e.g. from sys._getframe or
inspect.getouterframes), there's no way to get back to the function
object that created it. This creates an obstacle for various sorts of
introspection. In particular, in the unusual but real situation where
you need to "mark" a f
CC'ing PyPy-dev...
On Wed, May 24, 2017 at 6:01 PM, Eric Snow wrote:
> Although I haven't been able to achieve the pace that I originally
> wanted, I have been able to work on my multi-core Python idea
> little-by-little. Most notably, some of the blockers have been
> resolved at the recent PyCo
On May 24, 2017 20:31, "Guido van Rossum" wrote:
Hm... Curiously, I've heard a few people at PyCon mention they thought
subinterpreters were broken and not useful (and they share the GIL anyways)
and should be taken out. So we should at least have clarity on which
direction we want to take...
M
On Thu, May 25, 2017 at 12:01 PM, Eric Snow wrote:
> More significantly, I genuinely believe that isolated
> interpreters in the same process is a tool that many people will find
> extremely useful and will help the Python community. Consequently,
> exposing subinterpreters in the stdlib would re
On Sun, Jun 4, 2017 at 12:23 AM, Lucas Wiman wrote:
> I agree that the stated use cases are better handled with ExitStack. One
> area where `defer` might be useful is in lazy-evaluating global constants.
> For example in a genomics library used at my work, one module involves
> compiling a large
On Mon, Jun 5, 2017 at 4:14 AM, Nick Coghlan wrote:
> The biggest problem with this approach is that it means that adding
> new standard library modules becomes a backwards compatibility break -
> scripts that used to work will now fail since they'll get the standard
> library module rather than t
On Wed, Jun 14, 2017 at 1:54 PM, Barry Scott wrote:
> > On 13 Jun 2017, at 23:49, Chris Angelico wrote:
> > For that purpose, is it possible to use super().__dir__()? Are there
> > any considerations where that would fail?
>
> Remember that I need to do this in the C API and I want default_dir of
1 - 100 of 191 matches
Mail list logo
