On 17/02/17 10:22, 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)
Isn't this too general a syntax? Doesn't it lead to something like:
if a: b: c: d: e: pass
E.
_
On 18/02/17 19:35, Mikhail V wrote:
You mean what my proposal would bring
technically better than e.g.:
for i,e in enumerate(Seq)
Well, nothing, and I will simply use it,
with only difference it could be:
for i,e over enumerate(Seq)
In this case only space holes will be
smoothed out, so pure
On 03/03/17 19:02, Alexandre Brault wrote:
I believe what Matthias is hoping for is an equivalent of Java's named
break feature. Breaking out of an outer loop implicitly breaks out of
all inner loops
Yes, and although I think making this a runtime object is an interesting
thought (in terms of
Hi Brice,
On 04/03/17 08:45, Brice PARENT wrote:
* Creating a real object at runtime for each loop which needs to be
the target of a non-inner break or continue
However, I'm not sure the object should be constructed and fed for every
loop usage. It should probably only be instanciated if expl
On 06/03/17 03:08, David Mertz wrote:
On Sun, Mar 5, 2017 at 6:45 PM, Steven D'Aprano mailto:st...@pearwood.info>> wrote:
Here is a radical thought... why don't lists track their common type
themselves? There's only a few methods which can add items:
I had exactly the same thought. Li
On 07/03/17 20:46, Erik wrote:
(unless it
was acceptable that once heterogeneous, a list is always considered
heterogeneous - i.e., delete always sets the hint to NULL).
Rubbish. I meant that delete would not touch the hint at all.
E.
___
Python
Hi Elliot,
On 07/03/17 21:10, Elliot Gorokhovsky wrote:
On Tue, Mar 7, 2017 at 1:47 PM Erik mailto:pyt...@lucidity.plus.com>> wrote:
I'd prefer the sort optimization to be based on what my list contains
NOW, not on what it may have contained some time in the past, so I'
Hi David,
On 07/03/17 22:39, David Mertz wrote:
On Tue, Mar 7, 2017 at 4:36 PM, Erik mailto:pyt...@lucidity.plus.com>> wrote:
* Several other methods ('contains', 'remove', 'count', 'index')
also use PyObject_RichCompareBool(). They c
On 08/03/17 00:18, Steven D'Aprano wrote:
I thought about that and rejected it as an unnecessary complication.
Hetrogeneous and unknown might as well be the same state: either way,
you cannot use the homogeneous-type optimization.
Knowing it's definitely one of two positive states and not knowi
On 08/03/17 11:07, Steven D'Aprano wrote:
I mentioned earlier that I have code which has to track the type of list
items, and swaps to a different algorithm when the types are not all the
same.
Hmmm. Yes, I guess if the expensive version requires a lot of
isinstance() messing or similar for ea
On 09/03/17 23:04, Spencer Brown wrote:
Might make more sense to be dict.default(int), that way it doesn't
have redundant dict names.
I thought that, too.
since you could do {1:2, 3:4}.default(int)
Could you?
Python 3.6.0 (default, Mar 9 2017, 00:43:06)
[GCC 5.4.0 20160609] on linux
Type
Hi.
I may be way off-base here, but having scanned the patch I'm not sure I
agree that it's the right way forward.
What seems to be happening is that the homogeneity of the list is
determined somehow (whether tracked with a hint or scanned just-in-time)
and then a specific comparison functio
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 form:
def __init__(self, foo, bar, baz, spam, ham):
On 25/04/17 02:15, Chris Angelico wrote:
Bikeshedding: Your example looks a lot more like tuple assignment than
multiple assignment.
Well, originally, I thought it was just the spelling-the-same-name-twice
thing that irritated me and I was just going to suggest a single
assignment version lik
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
foil = foi1 + 1
foil += 1
Should one be silly enough t
On 25/04/17 22:15, Brice PARENT wrote:
it may be easier to get something like this
(I think, as there is no new operator involved) :
No new operator, but still a syntax change, so that doesn't help from
that POV.
def __init__(self, *args, **kwargs):
self.* = *args
self.** = **k
On 26/04/17 13:19, Joao S. O. Bueno wrote:
On 25 April 2017 at 19:30, Erik wrote:
decorators don't cut it anyway (at least not those
proposed) because they blindly assign ALL of the arguments. I'm more than
happy to hear of something that solves both of those problems without
need
On 26/04/17 08:59, Paul Moore wrote:
It should be possible to modify the decorator to take a list
of the variable names you want to assign, but I suspect you won't like
that
Now you're second-guessing me.
> class MyClass:
> @auto_args('a', 'b')
> def __init__(self, a, b, c=None):
>
On 26/04/17 18:42, Mike Miller wrote:
I want to be able to say:
def __init__(self, foo, bar, baz, spam):
self .= foo, bar, spam
self.baz = baz * 100
I don't see ALL being set a big problem, and less work than typing
several of them out again.
Because, some of the parameters might be th
On 26/04/17 16:10, Nick Timkovich wrote:
I was wondering that if there are so many arguments to a function that
it *looks* ugly, that it might just *be* ugly.
For one, too many required arguments to a function (constructor,
whatever) is already strange. Binding them as attributes of the object,
On 26/04/17 01:39, Nathaniel Smith wrote:
[snip discussion of why current augmented assignment operators are
better for other reasons]
Are there any similar arguments for .=?
It doesn't make anything more efficient, however all of the suggestions
of how to do it with current syntax (mostly
On 26/04/17 22:28, Paul Moore wrote:
On 26 April 2017 at 21:51, Erik wrote:
It doesn't make anything more efficient, however all of the suggestions of
how to do it with current syntax (mostly decorators) _do_ make things less
efficient.
Is instance creation the performance bottleneck in
On 26/04/17 19:15, Mike Miller wrote:
As the new syntax ideas piggyback on existing syntax, it doesn't feel
like that its a complete impossibility to have this solved. Could be
another "fixed papercut" to drive Py3 adoption. Taken individually not
a big deal but they add up.
*sigh* OK, this h
On 26/04/17 23:28, Paul Moore wrote:
Or to put it another way, if the only
reason for the syntax proposal is performance then show me a case
where performance is so critical that it warrants a language change.
It's the other way around.
The proposal (arguably) makes the code clearer but does n
On 27/04/17 23:43, Steven D'Aprano wrote:
On Wed, Apr 26, 2017 at 11:29:19PM +0100, Erik wrote:
def __init__(self, a, b, c):
self import a, b
self.foo = c * 100
[snarky]
If we're going to randomly choose arbitrary keywords with no connection
to the operation being perfor
On 28/04/17 10:47, Paul Moore wrote:
On 28 April 2017 at 00:18, Erik wrote:
The semantics are very different and there's little or no connection
between importing a module and setting an attribute on self.
At the technical level of what goes on under the covers, yes. At the higher
lev
On 02/05/17 12:31, Steven D'Aprano wrote:
I disagree with this approach. There's nothing special about bytes.hex()
here, perhaps we want to format the output of hex() or bin() or oct(),
or for that matter "%x" and any of the other string templates?
In fact, this is a string operation that could
On 26/04/17 21:50, Chris Angelico wrote:
On Thu, Apr 27, 2017 at 6:24 AM, Erik wrote:
The background is that what I find myself doing a lot of for private
projects is importing data from databases into a structured collection of
objects and then grouping and analyzing the data in different
On 03/05/17 01:43, Steven D'Aprano wrote:
On Tue, May 02, 2017 at 11:39:48PM +0100, Erik wrote:
On 02/05/17 12:31, Steven D'Aprano wrote:
Rather than duplicate the API and logic everywhere, I suggest we add a
new string method. My suggestion is str.chunk(size, delimiter=' &#
Hi Paul,
On 03/05/17 08:57, Paul Moore wrote:
> On 3 May 2017 at 02:48, Erik wrote:
>> Anyway, I know you can't stop anyone from *proposing* something like
this,
>> but as soon as they do you may decide to quote the recipe from
>> "https://docs.python.org/3/l
On 04/05/17 01:24, Steven D'Aprano wrote:
On Thu, May 04, 2017 at 12:13:25AM +0100, Erik wrote:
I had a use-case where splitting an iterable into a sequence of
same-sized chunks efficiently improved the performance of my code
[...]
So I didn't propose it. I have no idea now what
Hi Nick,
On 05/05/17 08:29, Nick Coghlan wrote:
And then given the proposed str.splitgroups() on the one hand, and the
existing memoryview.cast() on the other, offering
itertools.itergroups() as a corresponding building block specifically
for working with streams of regular data would make sense
On 21/05/17 15:43, Paul Laos wrote:
push(obj) would be
equivalent to insert(index = -1, object), having -1 as the default index
parameter. In fact, push() could replace both append() and insert() by
unifying them.
I don't think list.insert() with an index of -1 does what you think it does:
On 07/06/17 19:14, Nick Humrich wrote:
a, b, c = mydict.unpack('a', 'b', 'c')
def retrieve(mapping, *keys):
return (mapping[key] for key in keys)
$ python3
Python 3.5.2 (default, Nov 17 2016, 17:05:23)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more
On 07/06/17 23:42, C Anthony Risinger wrote:
Neither of these are really comparable to destructuring.
No, but they are comparable to the OP's suggested new built-in method
(without requiring each mapping type - not just dicts - to implement
it). That was what _I_ was responding to.
E.
_
[cross-posted to python-ideas]
Hi Robert,
On 16/06/17 12:32, Robert Vanden Eynde wrote:
Hello, I would like to propose an idea for the language but I don't know
where I can talk about it.
Can you please explain what the problem is that you are trying to solve?
In a nutshell, I would like to
On 19/06/17 02:47, David Mertz wrote:
As an only semi-joke, I have created a module on GH that meets the needs
of this discussion (using the spelling I think are most elegant):
https://github.com/DavidMertz/RLE
It's a shame you have to build that list when encoding. I tried to work
out a way
Hi,
On 11/09/16 10:36, Dominik Gresch wrote:
So I asked myself if a syntax as follows would be possible:
for i in range(10) if i != 5:
body
I've read the thread and I understand the general issues with making the
condition part of the expression.
However, what if this wasn't part of ch
On 09/10/16 12:43, Paul Moore wrote:
I'd probably lay this out as
# Less indent needed for keys, so thirdkey fits better in this case
mydict = {
'mykey': 'a very very very very very long value',
'secondkey': 'a short value',
'thirdkey':
'a very very very long value that conti
On 10/01/17 01:44, Simon Lovell wrote:
Regarding the logical inconsistency of my argument, well I am saying
that I would prefer my redundancy at the end of the loop rather than the
beginning. To say that the status quo is better is to say that you
prefer your redundancy at the beginning.
It's n
On 12/01/17 19:51, Todd wrote:
On Thu, Jan 12, 2017 at 2:33 PM, Sven R. Kunze mailto:srku...@mail.de>> wrote:
First of all, I am anti-censor and pro-change.
There is no "censorship" or "banning thoughts" going on here. Even with
this PEP, people are free to think about and talk about how
On Fri, Jun 2, 2017 at 7:52 AM, Greg Ewing wrote:
> Victor Stinner wrote:
>>
>> How do you write π (pi) with a keyboard on Windows, Linux or macOS?
>
>
> On a Mac, π is Option-p and ∑ is Option-w.
I don't have a strong opinion about it being in the stdlib, but I'd
also point out that a strong adv
Hi folks,
I normally wouldn't bring something like this up here, except I think
that there is possibility of something to be done--a language
documentation clarification if nothing else, though possibly an actual
code change as well.
I've been having an argument with a colleague over the last cou
On Wed, Jun 28, 2017 at 2:26 PM, Nick Coghlan wrote:
> On 28 June 2017 at 21:40, Erik Bray wrote:
>> My colleague's contention is that given
>>
>> lock = threading.Lock()
>>
>> this is simply *wrong*:
>>
>> lock.acquire()
>> tr
On Wed, Jun 28, 2017 at 3:09 PM, Erik Bray wrote:
> On Wed, Jun 28, 2017 at 2:26 PM, Nick Coghlan wrote:
>> On 28 June 2017 at 21:40, Erik Bray wrote:
>>> My colleague's contention is that given
>>>
>>> lock = threading.Lock()
>>>
>>
On Wed, Jun 28, 2017 at 3:19 PM, Greg Ewing wrote:
> Erik Bray wrote:
>>
>> At this point a potentially
>> waiting SIGINT is handled, resulting in KeyboardInterrupt being raised
>> while inside the with statement's suite, and finally block, and hence
>> Loc
On Fri, Jun 30, 2017 at 1:09 AM, Jan Kaliszewski wrote:
> 2017-06-25 Serhiy Storchaka dixit:
>
>> 25.06.17 15:06, lucas via Python-ideas пише:
>
>> > I often use generators, and itertools.chain on them.
>> > What about providing something like the following:
>> >
>> > a = (n for n in range(2
On Sun, Oct 29, 2017 at 8:45 PM, Alex Walters wrote:
> Then those users have more fundamental problems. There is a minimum level
> of computer knowledge needed to be successful in programming. Insulating
> users from the reality of the situation is not preparing them to be
> successful. Pretend
On Mon, Oct 30, 2017 at 11:27 AM, Erik Bray wrote:
> On Sun, Oct 29, 2017 at 8:45 PM, Alex Walters wrote:
>> Then those users have more fundamental problems. There is a minimum level
>> of computer knowledge needed to be successful in programming. Insulating
>> users fr
On Oct 30, 2017 8:57 PM, "Alex Walters" wrote:
> -Original Message-
> From: Python-ideas [mailto:python-ideas-bounces+tritium-
> list=sdamon@python.org] On Behalf Of Erik Bray
> Sent: Monday, October 30, 2017 6:28 AM
> To: Python-Ideas
> Subject: Re
On Nov 4, 2017 08:31, "Stephen J. Turnbull" <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
Erik Bray writes:
> Nope. I totally get that they don’t know what a shell or command prompt
> is. THEY. NEED. TO. LEARN.
Just to be clear I did not write this. Someone replying
ignedLong
PyLong_AsSize_t
PyLong_AsUnsignedLongLong
PyLong_AsDouble
PyLong_AsVoidPtr
I think this inconsistency should be fixed, unless there's some reason
for it I'm not seeing.
Thanks,
Erik
___
Python-ideas mailing list
Python-ideas@python.org
https
On Fri, Dec 8, 2017 at 12:26 PM, Serhiy Storchaka wrote:
> 08.12.17 12:41, Erik Bray пише:
>>
>> IIUC, it seems to be carry-over from Python 2's PyLong API, but I
>> don't see an obvious reason for it. In every case there's an explicit
>> PyLong_C
On Fri, Dec 8, 2017 at 1:52 PM, Antoine Pitrou wrote:
> On Fri, 8 Dec 2017 14:30:00 +0200
> Serhiy Storchaka
> wrote:
>>
>> NumPy integers implement __index__.
>
> That doesn't help if a function calls e.g. PyLong_AsLongAndOverflow().
Right--pointing to __index__ basically implies that PyIndex_C
On Fri, Dec 8, 2017 at 7:20 PM, Ethan Furman wrote:
> On 12/08/2017 04:33 AM, Erik Bray wrote:
>
>> More importantly not as many objects that coerce to int actually
>> implement __index__. They probably *should* but there seems to be
>> some confusion about how that
On Thu, Dec 28, 2017 at 8:42 PM, Serhiy Storchaka wrote:
> 28.12.17 12:10, Erik Bray пише:
>>
>> There's no index() alternative to int().
>
>
> operator.index()
Okay, and it's broken. That doesn't change my other point that some
functions that could p
Hello,
Brief problem statement: Let's say I have a custom file type (say,
with extension .foo) and these .foo files are included in a package
(along with other Python modules with standard extensions like .py and
.so), and I want to make these .foo files importable like any other
module.
On its f
On Fri, Mar 23, 2018 at 11:25 AM, Antoine Pitrou wrote:
> On Fri, 23 Mar 2018 07:25:33 +0100
> Jeroen Demeyer wrote:
>
>> On 2018-03-23 00:36, Antoine Pitrou wrote:
>> > It does make sense, since the proposal sounds ambitious (and perhaps
>> > impossible without breaking compatibility).
>>
>> Wel
On Tue, Apr 10, 2018 at 9:50 PM, Eric V. Smith wrote:
>
>>> 3. Annotations. They are used mainly by third party tools that
>>> statically analyze sources. They are rarely used at runtime.
>>
>> Even less used than docstrings probably.
>
> typing.NamedTuple and dataclasses use annotations at runtim
On Fri, Sep 21, 2018 at 12:58 AM Chris Angelico wrote:
>
> On Fri, Sep 21, 2018 at 8:52 AM Kyle Lahnakoski
> wrote:
> > Since the java.lang.Thread.stop() "debacle", it has been obvious that
> > stopping code to run other code has been dangerous. KeyboardInterrupt
> > (any interrupt really) is d
On Mon, Oct 8, 2018 at 12:23 PM Nathaniel Smith wrote:
>
> 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 dependenc
On Mon, Oct 8, 2018 at 12:20 PM Cameron Simpson wrote:
>
> On 08Oct2018 10:56, Ram Rachum wrote:
> >That's incredibly interesting. I've never used mmap before.
> >However, there's a problem.
> >I did a few experiments with mmap now, this is the latest:
> >
> >path = pathlib.Path(r'P:\huge_file')
ome related discussion in
https://mail.python.org/archives/list/python-ideas@python.org/thread/QVTGZD6USSC34D4IJG76UPKZRXBBB4MM/
but not this exact idea.
Erik
--
Erik Demaine | edema...@mit.edu | http://erikdemaine.org/
___
Python-ideas mai
what we have now, and is far more flexible than just extracting the first
element. The distinction from the existing methods (with e.g. `*_`) is that
it wouldn't waste time extracting elements you don't want. And it could work
well with things like `dict` (and `dict
ell.) I wonder about some generalized mechanism for automatically setting
the __name__ of an assigned object (like def and class), but I'm not sure what
it would look like...
Erik
--
Erik Demaine | edema...@mit.edu | http://erikdemaine.org/
___
nt to `list1.extend([a, b])`?
It is in JavaScript (`Array.push`). And I don't see why one would expect
it to append a tuple `(a, b)`; that's what `list1.append((a, b))` is for.
I think the main argument against this is to avoid programming errors,
which is fine, but I don't see why i
On Sat, 16 Oct 2021, David Mertz, Ph.D. wrote:
On Sat, Oct 16, 2021, 10:10 AM Erik Demaine
(*it1, *it2, *it3) # tuple with the concatenation of three
iterables
[*it1, *it2, *it3] # list with the concatenation of three
iterables
{*it1, *it2, *it3} # set with the
On Sun, 17 Oct 2021, Steven D'Aprano wrote:
On Sat, Oct 16, 2021 at 11:42:49AM -0400, Erik Demaine wrote:
I guess the question is whether to define `(*it for it in its)` to mean
tuple or generator comprehension or nothing at all.
I don't see why that is even a question. We don&#x
@, not
an argument, more like `def f(@later arg = default)`.
* I'm not very familiar with thunks, but they seem a bit too magical for my
liking. Evaluating argument defaults only sometimes (when they get read in
the body) feels a bit unpredictable.
Erik
--
Erik Demaine | edema...
e actual
semantics. Changing the PEP accordingly.
I think the semantics are easy to specify: the argument defaults get evaluated
for unspecified order, in left to right order as specified in the def. Those
may trigger exceptions as usual.
Erik
___
On Sun, 24 Oct 2021, Erik Demaine wrote:
I think the semantics are easy to specify: the argument defaults get
evaluated for unspecified order, in left to right order as specified in the
def. Those may trigger exceptions as usual.
Sorry, that should be:
I think the semantics are easy to
no_a, b = _no_b, c = _no_c):
(a := expr1 if a is _no_a else a,
b := expr2 if b is _no_b else b,
c := expr3 if c is _no_c else c)
```
Given that `=` assignments within a function's parameter spec already only
means "assign when another value isn't specified", this i
ed, `y` won't get assigned.) This would suggest evaluating default
expressions in their own scope would be beneficial. Intuitively, the parens
are indicating a separate scope, in the same way that `(x for x in it)`
creates its own scope and thus doesn't leak `x`. On the other h
On Sat, 16 Oct 2021, Erik Demaine wrote:
Assuming the support remains relatively unanimous for [*...], {*...}, and
{**...} (thanks for all the quick replies!), I'll put together a PEP.
As promised, I put together a pre-PEP (together with my friend and coteacher
Adam Hartz, not curr
7;t solve the default parameter problem, because they'll be evaluated
in the function's enclosing scope instead of the function's scope.
Erik
--
Erik Demaine | edema...@mit.edu | http://erikdemaine.org/
___
Python-ideas mail
quot;There are no hidden details as to what a function's call
signature is."? (This may be a very short-lived thread.)
Erik
--
Erik Demaine | edema...@mit.edu | http://erikdemaine.org/
___
Python-ideas mailing list -- python-ideas@pyt
ate-binding defaults:
```
f(_missing, {'more'})
g(_missing, {'more'})
```
I started thinking about `_missing` when thinking about how to implement
late-binding defaults. It's at least one way to do it (then the function
itself co
1a7b9f
On the plus side, this probably means that there aren't many people using the
hi=None API. :-) So it might be safe to change to a late-bound default.
Erik
--
Erik Demaine | edema...@mit.edu | http://erikdemaine.org/___
Python-ideas mai
ore. I don't recall
enjoying it. But maybe I missed a proposal, or someone has an idea for how to
fix these issues.
Erik
--
Erik Demaine | edema...@mit.edu | http://erikdemaine.org/
___
Python-ideas mailing list -- python-ideas@python.org
To
On Sat, 30 Oct 2021, Erik Demaine wrote:
Functions are already a form of deferred evaluation. PEP 671 is an
embellishment to this mechanism for some of the code in the function
signature to actually get executed within the body scope, *just like the body
of the function*.
I was thinking
ding scopes.
Sure. Explore anything you like! But I don't think that this is any less
ugly than either the status quo or PEP 671, both of which involve actual
real code being parsed by the compiler.
This proposal was meant to help define what the compiler with PEP 671 parsed
code
On Mon, Aug 29, 2016 at 9:07 AM, Ken Kundert
wrote:
> On Mon, Aug 29, 2016 at 01:45:20PM +1000, Steven D'Aprano wrote:
>> On Sun, Aug 28, 2016 at 08:26:38PM -0700, Brendan Barnwell wrote:
>> > On 2016-08-28 18:44, Ken Kundert wrote:
>> > >When working with a general purpose programming language, t
On Mon, Aug 29, 2016 at 3:05 PM, Erik Bray wrote:
> On Mon, Aug 29, 2016 at 9:07 AM, Ken Kundert
> wrote:
>> On Mon, Aug 29, 2016 at 01:45:20PM +1000, Steven D'Aprano wrote:
>>> On Sun, Aug 28, 2016 at 08:26:38PM -0700, Brendan Barnwell wrote:
>>> >
the butt of the joke
rather than the "witch", this joke doesn't necessarily play well
universally, especially given that there places today where women are
being killed for being "witches".
Best,
Erik
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
On Tue, Aug 30, 2016 at 5:48 AM, Ken Kundert
wrote:
> Erik,
> One aspect of astropy.units that differs significantly from what I am
> proposing is that with astropy.units a user would explicitly specify the scale
> factor along with the units, and that scale factor would not ch
ython newbie being confused that they can write
"for x in y if z" inside a list comprehension, but not in a bare
for-statement. Sure they'd learn quickly enough that the filtering
syntax is unique to list comprehensions. But to anyone who doesn't
know the historical
On Tue, Sep 27, 2016 at 5:33 PM, Nick Coghlan wrote:
> On 28 September 2016 at 00:55, Erik Bray wrote:
>> On Sun, Sep 11, 2016 at 12:28 PM, Bernardo Sulzbach
>> wrote:
>>> On 09/11/2016 06:36 AM, Dominik Gresch wrote:
>>>>
>>>> So I asked
very very'
> ' long value that continues on the next line',
> }
Heh--not to bikeshed, but my personal preference is to leave the
trailing space on the first line. This is because by the time I've
started a new line (and possibly have spe
initial version of a patch [5] is available on the bug tracker for
this issue. The patch is proposed and written by Masayuki Yamamoto,
who should be considered a co-author of this proto-PEP, though I have
not consulted directly with him in writing this. If he's reading, he
should chime in i
On Sun, Dec 18, 2016 at 12:10 AM, Masayuki YAMAMOTO
wrote:
> 2016-12-17 18:35 GMT+09:00 Stephen J. Turnbull
> :
>>
>> I don't understand this. I assume that there are no such platforms
>> supported at present. I would think that when such a platform becomes
>> supported, code supporting "key" fu
On Sat, Dec 17, 2016 at 8:21 AM, Stephen J. Turnbull
wrote:
> Erik Bray writes:
>
> > Abstract
> >
> >
> > The proposal is to add a new Thread Local Storage (TLS) API to CPython
> > which would supersede use of the existing TLS API within
On Mon, Dec 19, 2016 at 1:11 PM, Nick Coghlan wrote:
> On 17 December 2016 at 03:51, Antoine Pitrou wrote:
>>
>> On Fri, 16 Dec 2016 13:07:46 +0100
>> Erik Bray wrote:
>> > Greetings all,
>> >
>> > I wanted to bring attention to an issue that&
On Mon, Dec 19, 2016 at 3:45 PM, Erik Bray wrote:
> On Mon, Dec 19, 2016 at 1:11 PM, Nick Coghlan wrote:
>> On 17 December 2016 at 03:51, Antoine Pitrou wrote:
>>>
>>> On Fri, 16 Dec 2016 13:07:46 +0100
>>> Erik Bray wrote:
>>> > Greetings al
On Tue, Dec 20, 2016 at 9:26 AM, Nick Coghlan wrote:
> On 20 December 2016 at 00:53, Erik Bray wrote:
>>
>> On Mon, Dec 19, 2016 at 3:45 PM, Erik Bray wrote:
>> >> Likewise - we know the status quo isn't right, and the proposed change
>> >> addresses
On Wed, Dec 21, 2016 at 2:10 AM, Nick Coghlan wrote:
> On 21 December 2016 at 01:35, Masayuki YAMAMOTO
> wrote:
>>
>> 2016-12-20 22:30 GMT+09:00 Erik Bray :
>>>
>>> This is probably an implementation detail, but ISTM that even with
>>> PyThread_call
On Wed, Dec 21, 2016 at 11:01 AM, Erik Bray wrote:
> That all sounds good--between the two option 2 looks a bit more explicit.
>
> Though what about this? Rather than adding another type, the original
> proposal could be changed slightly so that Py_tss_t *is* partially
> defi
On Wed, Dec 21, 2016 at 5:07 PM, Nick Coghlan wrote:
> On 21 December 2016 at 20:01, Erik Bray wrote:
>>
>> On Wed, Dec 21, 2016 at 2:10 AM, Nick Coghlan wrote:
>> > Option 2: Similar to option 1, but using a custom type alias, rather
>> > than
>> &g
On Fri, Dec 30, 2016 at 5:05 PM, Nick Coghlan wrote:
> On 29 December 2016 at 22:12, Erik Bray wrote:
>>
>> 1) CPython's TLS: Defines -1 as an uninitialized key (by fact of the
>> implementation--that the keys are integers starting from zero)
>> 2) pthreads: Do
98 matches
Mail list logo
