Hi
When looking at the pydebug.h header file, I see that some symbols are not
declared as exported.
For instance, I would like to be able to change the value of the
Py_TabcheckFlag when running specific codelines.
Any chance this patch could be added ?
Thanks for your feedback,
Eloi
Index: In
Hi
I would like to be able to get an handle on PyGC_Head*_PyGC_generation0 from a
CPython extension.
This is possible when building Python on a Posix host, but not on Windows
because of a missing PyAPI_DATA wrapping of the said object in the objimpl.h
header.
Having the possibility to inspect
On Fri, Oct 18, 2019, 1:00 PM GAUDRY Eloi wrote:
> Hi
>
> When looking at the pydebug.h header file, I see that some symbols are not
> declared as exported.
> For instance, I would like to be able to change the value of the
> Py_TabcheckFlag when running specific codelines.
> Any chance this patc
Hi Ethan,
Le ven. 18 oct. 2019 à 04:38, Ethan Furman a écrit :
> > To remain relevant and useful, Python has to evolve frequently. Some
> > enhancements require incompatible changes. Any incompatible change can
> > break an unknown number of Python projects. Developers can decide to
> > not impl
On Thu, Oct 17, 2019 at 7:35 AM Brandt Bucher
wrote:
> Please let us know what you think – we'd love to hear any *new* feedback
> that hasn't yet been addressed in the PEP or the related discussions it
> links to! We plan on updating the PEP at least once more before review.
I, personally, do n
On Fri, Oct 18, 2019 at 11:41 PM Richard Musil wrote:
>
> I know this has been somewhat addressed in PEP, but I simply cannot see, how
> adding another ambiguity to the '+' symbol, can be better, because the
> "familiarity" of '+' (which seems to me being an argument in the PEP) just
> hides th
I was recently playing around with decorators and experimenting with
defining a function's signature dynamically at runtime, and came across the
builtins.function class constructor (more easily accessible through the
types.FunctionType alias). I quickly realized, however, that even though
the const
On Fri, Oct 18, 2019 at 2:49 PM Chris Angelico wrote:
> On Fri, Oct 18, 2019 at 11:41 PM Richard Musil
> wrote:
> >
> > I know this has been somewhat addressed in PEP, but I simply cannot see,
> how adding another ambiguity to the '+' symbol, can be better, because the
> "familiarity" of '+' (wh
Just thinking aloud here but when you say "positional" parameters you mean
normal parameters and not positional only parameters as introduced in 3.8 right?
And how would those fit into this picture?
> On 18 Oct 2019, at 15:31, Gus Wiedey wrote:
>
>
> I was recently playing around with decora
On Fri, 18 Oct 2019 at 14:33, Richard Musil wrote:
> I have no problem with any example you mentioned above, yet I consider
> proposed meaning for '+' symbol in this PEP context fundamentally different
> from either "arithmetic" or "concatenation" meaning, used in the previous
> examples, becau
Paul Moore wrote:
> All of the above is just my subjective opinion. Objective information is
> likely to only be available by someone looking at a body of real world code
> and demonstrating what difference the proposed operator would make to it
> (maybe someone did that already - I've not been
On Fri, 18 Oct 2019 at 14:57, Brandt Bucher wrote:
>
> Paul Moore wrote:
> > All of the above is just my subjective opinion. Objective information is
> > likely to only be available by someone looking at a body of real world code
> > and demonstrating what difference the proposed operator would
> On 18 Oct 2019, at 15:58, Brandt Bucher wrote:
>
> Paul Moore wrote:
>> All of the above is just my subjective opinion. Objective information is
>> likely to only be available by someone looking at a body of real world code
>> and demonstrating what difference the proposed operator would m
On 18/10/2019 15:43, Anders Hovmöller wrote:
On 18 Oct 2019, at 15:58, Brandt Bucher wrote:
Basically the whole bottom quarter of the PEP!
https://www.python.org/dev/peps/pep-0584/#examples-of-candidates-for-the-dict-merging-operator
The examples would make more sense if the "before" pictu
On Oct 18, 2019, at 06:49, Paul Moore wrote:
>
> IMO, debating the "meaning" of addition, and whether the + operator is
> appropriate here, is not the key question. The real questions for me
> are whether the update operation is used frequently enough to require
> an additional way of spelling it
On 10/16/2019 10:35 PM, Brandt Bucher wrote:
At long last, Steven D'Aprano and I have pushed a second draft of PEP 584
(dictionary addition):
Please let us know what you think – we'd love to hear any *new* feedback that
hasn't yet been addressed in the PEP or the related discussions it link
On Oct 18, 2019, at 06:31, Richard Musil wrote:
>
> Technically we can call set union also an "add" operation, yet we use
> different semantics to express it, for exactly the same reason, it is not
> "arithmetic" nor, "concatenation", but something different.
Set union had analogies to two dif
On Fri, Oct 18, 2019 at 02:39:41PM +0200, Richard Musil wrote:
> ```
> a = dict(...)
> b = dict(...)
> c = a |< b
> ```
> 2) Anyone finding this in the code, who does not now about the operator,
> will _not_ guess the wrong operation.
That's certainly true, but only because they will have absolu
i'm a -0 on the PEP.
that being said, I am sure i will probably use the hell out of it. it is
very convenient syntax for mashing together several mappings:
# yuck
for d in dict_seq:
my_dict.update(d)
# not much better
{**d1, **d2, **d3}
but i'm -0 because i am very concerned it will not be
On Fri, Oct 18, 2019 at 09:17:54AM -0700, Ethan Furman wrote:
> That result just doesn't match up with the '+' operator.
Why not?
Before answering, please check the PEP to see if your objection has
already been raised.
Addition and the plus operator is flexible enough to be used for
everythin
On 2019-10-18 17:31, Andrew Barnert via Python-ideas wrote:
On Oct 18, 2019, at 06:31, Richard Musil wrote:
Technically we can call set union also an "add" operation, yet we use different semantics to
express it, for exactly the same reason, it is not "arithmetic" nor, "concatenation", but
s
On Oct 18, 2019, at 09:33, Steven D'Aprano wrote:
>
> That's certainly true, but only because they will have absolutely no
> clue at all about what |< could possibly mean. "Bitwise-or less-than"
> perhaps, whatever that could mean.
>
> You seem to have come up with a completely unique symbol w
The implementation starts here:
https://github.com/python/cpython/blob/ecb035cd14c11521276343397151929a94018a22/Objects/funcobject.c#L499
The argument clinic input specifying the signature is a few lines above.
Clinic's output is here:
https://github.com/python/cpython/blob/master/Objects/clinic/f
This looks like an issue for bugs.python.org. After opening a bug there you
could also try to fix this yourself and submit a Pull Request (see the
Python devguide).
On Fri, Oct 18, 2019 at 3:10 AM GAUDRY Eloi wrote:
> Hi
>
> I would like to be able to get an handle on PyGC_Head*_PyGC_generation0
Please submit this to bugs.python.org.
On Fri, Oct 18, 2019 at 3:02 AM GAUDRY Eloi wrote:
> Hi
>
> When looking at the pydebug.h header file, I see that some symbols are not
> declared as exported.
> For instance, I would like to be able to change the value of the
> Py_TabcheckFlag when running
On Thu, Oct 17, 2019 at 7:39 PM Ethan Furman wrote:
> On 10/17/2019 06:02 PM, Victor Stinner wrote:
>
> > I propose the following PEP to add
> > sys.set_python_compat_version(version) to introduce a partial
> > compatibility with Python 3.8 in the next Python 3.9 version.
>
> -1
>
-1 from me as
I suspect this proposal contradicts with CPython movement to close as
many implementation details as possible.
On Fri, Oct 18, 2019 at 9:28 PM Guido van Rossum wrote:
>
> This looks like an issue for bugs.python.org. After opening a bug there you
> could also try to fix this yourself and submit
First of all, thank you for telling me this. I didn't even know that
positional-only parameters existed at all until a few days ago when I
discovered them while exploring this issue, let alone that they had been
added to Python functions in 3.8.
Second, after poking around a bit in 3.8, it looks l
I actually have a commit already made, but I realized there is one possible
complication that I may have overlooked: if there are keys in
__kwdefaults__ that don't correspond to any explicitly-named arguments in
the signature, will those get ignored or could they cause problems?
On Fri, Oct 18, 20
On 10/18/2019 10:25 AM, Steven D'Aprano wrote:
On Fri, Oct 18, 2019 at 09:17:54AM -0700, Ethan Furman wrote:
That result just doesn't match up with the '+' operator.
Why not?
Pretty sure I answered that question in my OP. Here it is again since you
conveniently stripped it out:
The prob
On Fri, Oct 18, 2019 at 6:39 PM Steven D'Aprano wrote:
> You seem to have come up with a completely unique symbol which has, as
> far as I can tell, never been used before. As far as I can see, neither
> APL nor Perl use it as an operator. I can't see it in Unicode, or as an
> emoticon.
>
What i
On Oct 18, 2019, at 12:17, Gus Wiedey wrote:
>
> I actually have a commit already made, but I realized there is one possible
> complication that I may have overlooked: if there are keys in __kwdefaults__
> that don't correspond to any explicitly-named arguments in the signature,
> will those g
32 matches
Mail list logo
