Thanks. I will do it.
On Wed, Jul 1, 2020 at 5:50 PM Serhiy Storchaka wrote:
>
> 01.07.20 04:35, Inada Naoki пише:
> > Hi, folks.
> >
> > I found PyEval_AcquireLock and PyEval_ReleaseLock are deprecated since
> > Python 3.2.
> > But the same time, stable ABI is defined in Python 3.2 too.
> > The
I don't think my proposal should be off the table for scope reasons because it
requires the syntaxes to be completely unified and interchangeable, which will
be impossible if the current PEP is accepted. I guess it's technically possible
to still have the pattern-matching syntax be slightly diff
On Wed, Jul 1, 2020 at 5:50 PM Nick Coghlan wrote:
> The key thing I'm hoping for in PEP 622 itself is that "Syntactic
> compatibility with a possible future enhancement to assignment
> statements" be considered as a constraint on the syntax for case
> patterns.
>
That would certainly rule out i
On Thu, 2 Jul 2020 at 00:50, Guido van Rossum wrote:
>
> Before we all get a little too excited here, I think that allowing
> ```
> 1 = x
> ```
> as a sneaky way of writing
> ```
> assert x == 1
> ```
> would be a terrible mistake.
The "two ways to do it" possibilities give me pause too, but it
w
I agree with you it is over the top, but let's enjoy the popcorn together!
On Wed, 1 Jul 2020 at 01:35, Greg Ewing wrote:
> Sorry for fanning the flames, but this whole thread is so over
> the top I'm finding it kind of entertaining.
>
> On 1/07/20 2:23 am, Piper Thunstrom wrote:
> > The grammar
To paraphrase the Bible: "For where two or three gather, there is politics
with them."
Changing the commit message, as it has been merged, is now practically hard
and highly unusual. If you use GitHub search, you can find other examples
of commit messages that would be rewritten if that was doable
We're trying to make the PEP's scope *smaller*, not larger. Let's take
changes to assignment off the table. We're fully aware of the resemblance
between `a, b = value` and `case a, b: ...` and we're making them behave as
similar as is reasonable.
On Wed, Jul 1, 2020 at 4:29 PM Daniel Moisset wrot
On 2/07/20 9:25 am, Matthias Bussonnier wrote:
It's still weird user experience as if you swap case .z and case z you don't
get the Unbound error anymore.
It also won't work as intended, because 'case z' will always match
and it will never get to 'case .z'.
--
Greg
___
On Thu, Jul 2, 2020 at 5:20 AM M.-A. Lemburg wrote:
>
>
> The reasoning here is the same as for decoding: you have the original
> data you want to process available in some array and want to turn
> this into the Python object.
>
> The path Victor suggested requires always going via a Python Unicod
If I was to do this in Python, rather than the Rust way of forbidding
refutable patterns, I would put as a rule that the target must have at
least one variable to bind* . It makes sense in the context that the goals
of an assignment are the bindings it does, and the ValueError is an
accident that t
On 2/07/20 4:54 am, Brandt Bucher wrote:
It sounds like you want to add "global z" to the top of the function definition.
Or more likely, change the last case to 'case _'.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe se
On Wed, Jul 1, 2020 at 11:31 AM Elliott Chen
wrote:
> I guess it might work in a separate PEP, but I'm also a little worried
> because the current PEP would make that impossible with its subtle
> incompatibilities with the existing unpacking syntax. Or even more
> inconsistent, if the assignment
On Wed, 1 Jul 2020 at 15:50, Guido van Rossum wrote:
> Before we all get a little too excited here, I think that allowing
> ```
> 1 = x
> ```
> as a sneaky way of writing
> ```
> assert x == 1
> ```
> would be a terrible mistake.
>
Well, we'll always have the sneaky way to check if an iterable i
There is the https://github.com/pyhandle/hpy project which is
implemented on top of the existing C API.
But this project doesn't solve problems listed in PEP 620, since
CPython must continue to support existing C extensions.
Victor
Le mer. 1 juil. 2020 à 23:43, Eric V. Smith a écrit :
>
> On 7/
On Thu, 2 Jul 2020 at 09:28, Matthias Bussonnier
wrote:
>
> It's still weird user experience as if you swap case .z and case z you don't
> get the Unbound error anymore. SO it can work w/o global.
For some value of work: if z comes before .z, the .z branch will never
get evaluated, because the b
On 7/1/2020 3:43 PM, Stefan Behnel wrote:
Petr Viktorin schrieb am 30.06.20 um 14:51:
For example, could we only deprecate the bad parts, but not remove them
until the experiments actually show that they are preventing a beneficial
change?
Big nod on this one.
At one of the core sprints (mayb
On 7/1/2020 1:20 PM, M.-A. Lemburg wrote:
As an example application, think of a database module which provides
the Unicode data as Py_UNICODE buffer. You want to write this as UTF-8
data to a file or a socket, so you have the PyUnicode_EncodeUTF8() API
decode this for you into a bytes object whic
It's still weird user experience as if you swap case .z and case z you don't
get the Unbound error anymore. SO it can work w/o global.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https:
On 30.06.2020 15:17, Victor Stinner wrote:
> Le mar. 30 juin 2020 à 13:53, M.-A. Lemburg a écrit :
>>> I would prefer to analyze the list on a case by case basis. I don't
>>> think that it's useful to expose every single encoding supported by
>>> Python as a C function.
>>
>> (...)
>> This does no
On 28.06.2020 16:24, Inada Naoki wrote:
> Hi, Lamburg.
>
> Thank you for quick response.
>
>>
>> We can't just remove access to one half of a codec (the decoding
>> part) without at least providing an alternative for C extensions
>> to use.
>>
>> Py_UNICODE can be removed from the API, but only i
On 06/29/2020 06:21 AM, Nathaniel Smith wrote:
It's not Strunk and White per se, it's the idea of enforcing "standard
English", where "standard" here means "talks like a American with an
Ivy league education".
I believe the issue is writing, not talking.
There's nothing wrong with being igno
On 06/30/2020 07:07 AM, Giampaolo Rodola' wrote:
On Tue, Jun 30, 2020 at 3:16 PM Thomas Wouters wrote:
Please report all CoC violations to the CoC WG.
Please don't. As far as I'm concerned, me and Thomas are fine. Also,
as I said, I don't like CoCs nor appealing to them.
This is a public
Petr Viktorin schrieb am 30.06.20 um 14:51:
> For example, could we only deprecate the bad parts, but not remove them
> until the experiments actually show that they are preventing a beneficial
> change?
Big nod on this one.
Stefan
___
Python-Dev mailin
I guess it might work in a separate PEP, but I'm also a little worried because
the current PEP would make that impossible with its subtle incompatibilities
with the existing unpacking syntax. Or even more inconsistent, if the
assignment target syntax is extended to become similar to the match sy
Walter Dörwald wrote:
> This looks strange to me. In all other cases of variable lookup the global
> variable z would be found.
The next case assigns to z, making z local to whereis. This is consistent with
python's existing scoping rules (for example, try rewriting this as the
equivalent if-el
On 1 Jul 2020, at 17:58, Guido van Rossum wrote:
If you are interested in learning more about how PEP 622 would work in
practice, but don't feel like compiling a Python 3.10 fork from
source,
here's good news for you.
In a hurry?
https://mybinder.org/v2/gh/gvanrossum/patma/master?urlpath=lab/
If you are interested in learning more about how PEP 622 would work in
practice, but don't feel like compiling a Python 3.10 fork from source,
here's good news for you.
In a hurry?
https://mybinder.org/v2/gh/gvanrossum/patma/master?urlpath=lab/tree/playground-622.ipynb
This will open a Binder ins
On 01/07/2020 15:50, Guido van Rossum wrote:
Before we all get a little too excited here, I think that allowing
```
1 = x
```
as a sneaky way of writing
```
assert x == 1
```
would be a terrible mistake.
+1
One of Python's major virtues is that it's pretty easy to read and get
the gist of wha
Before we all get a little too excited here, I think that allowing
```
1 = x
```
as a sneaky way of writing
```
assert x == 1
```
would be a terrible mistake.
We already have a static way to assert that something is a string:
```
self.name: str = value
```
I don't think that we'll need another way
On Thu, 2 Jul 2020 at 00:04, Elliott Chen wrote:
>
> I saw in the PEP that "Allow more flexible assignment targets instead" was
> rejected, but I actually think it's a good idea. The current PEP means there
> will be two different, subtly incompatible ways to destructure objects (match
> statem
I saw in the PEP that "Allow more flexible assignment targets instead" was
rejected, but I actually think it's a good idea. The current PEP means there
will be two different, subtly incompatible ways to destructure objects (match
statement and iterable unpacking). The reasoning given was that mo
On Wed, Jul 1, 2020 at 4:09 AM Antoine Pitrou wrote:
> How does this help third-party extensions?
>
If the cost is high enough, exposing the guts of a function to allow the
compiler to inline it is not unreasonable; all of the major compilers have
ways to inline things that are technically acros
On Tue, Jun 30, 2020 at 3:09 PM Petr Viktorin wrote:
> On 2020-06-30 02:46, Victor Stinner wrote:
> > You missed the point of the PEP: "It becomes possible to experiment
> > with more advanced optimizations in CPython than just
> > micro-optimizations, like tagged pointers."
>
> I don't think exp
On Wed, 1 Jul 2020 12:50:01 +0200
Victor Stinner wrote:
> Le mer. 1 juil. 2020 à 03:53, Inada Naoki a écrit :
> > I confirmed the performance regression, although the difference is 12%.
> > And I find the commit cause the regression.
> >
> > https://github.com/python/cpython/commit/45ec5b99aefa54
Le mer. 1 juil. 2020 à 03:53, Inada Naoki a écrit :
> I confirmed the performance regression, although the difference is 12%.
> And I find the commit cause the regression.
>
> https://github.com/python/cpython/commit/45ec5b99aefa54552947049086e87ec01bc2fc9a
> https://bugs.python.org/issue40170
>
>
01.07.20 04:35, Inada Naoki пише:
Hi, folks.
I found PyEval_AcquireLock and PyEval_ReleaseLock are deprecated since
Python 3.2.
But the same time, stable ABI is defined in Python 3.2 too.
The deprecated APIs are stable ABI too because `ceval.h` is not
excluded from the stable ABI PEP.
As far as
36 matches
Mail list logo
