[Python-Dev] 0xfor 3. Parser bug?
This was just posted on SO https://stackoverflow.com/questions/67083039/why-does-python-return-15-for-0xfor-x-in-1-2-3 I can reproduce it with a simpler example >>> 0xfor 3 15 Is it a bug in the parser, or working as intended? It's not only for hex. This works to >>> 3or 50 3 -- Kind regards, Stefano Borini ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/V6HMVBY4DO7IB7MQO2CAZFY7RJWAV7BB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: On the migration from master to main
On Tue, 23 Mar 2021 at 21:39, Python Steering Council wrote: > This isn’t just about ‘master’ being rooted in slavery. No it's not and I am shocked that such ignorance would exist to believe that. -- Kind regards, Stefano Borini ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LNUIPXM7S5SK7VMGVHYROTLJTNIR62LM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Rejecting PEP 637 (Support for indexing with keyword arguments)
All right. Thanks for the feedback. Brandt should we terminate the branch, or restructure it for the *args mechanics? On Mon, 15 Mar 2021 at 18:43, Thomas Wouters wrote: > > > Hi Stefano, > > Thank you for submitting PEP 637 (Support for indexing with keyword > arguments). The Steering Council has reviewed the PEP and after careful > consideration, we have decided to reject the PEP. There are a number of > reasons for this, but fundamentally we do not believe the benefit is great > enough to outweigh the cost of the new syntax. > > The benefits of the new syntax as outlined in the PEP are not particularly > strong, and community support for the new syntax seems low. The new syntax > doesn’t provide an obvious way to do something that is currently error-prone, > and doesn’t open up new possibilities that were not possible before. While > there are certainly cases that could use the new syntax, for many of them > it’s not clear that it would be a win, or that third-party libraries would > indeed use the syntax. The Steering Council isn’t really convinced by any of > the suggested uses in the PEP. > > The strongest argument for the new syntax comes from the typing side of > Python. The Steering Council is not particularly convinced it is of > significant benefit to the static type checking language, but even if it > were, at this point we’re reluctant to add general Python syntax that only > (or mostly) benefits the static typing language. If the syntax would be of > great benefit to static typing, it might be time to discuss letting go of the > requirement that the typing language be a subset of Python -- but whether > this feature is important enough to consider that is up to the typing > community. > > The SC considers the cost of the new syntax significant. It’s not a natural > fit, as shown by the corner cases discussed in the PEP. It’s difficult to > teach, as indexing and function calls are not as interchangeable or > equivalent as they may appear. Looking at more complex expressions with the > new syntax, mentally parsing them is significantly harder than the equivalent > without the new syntax, even if it requires more lines of code to do the same > thing. > > In addition to all that, the SC is worried about the performance of indexing > in CPython and in other Python implementations, considering it’s a very > common operation, and about the suggested new __getitem__ protocol, > particularly the confusing corner cases of indexing with keywords and zero or > one positional items. These are not, however, the main reason we decided to > reject the PEP. > > With our appreciation, > For the whole Python Steering Council, > Thomas. > -- > Thomas Wouters > > Hi! I'm an email virus! Think twice before sending your email to help me > spread! -- Kind regards, Stefano Borini ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/66I2QLDYYHZ6MMVSTLGIQ74NY6XV2YVZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 637 - Support for indexing with keyword arguments: request for feedback for SC submission
If interested, you can try it out from my github branch: https://github.com/stefanoborini/cpython/tree/PEP-637-implementation-attempt-2 I am going to sync it against python master in a few minutes (it's been a while, there probably will be conflicts). Please break it. On Thu, 25 Feb 2021 at 16:41, Thor Whalen wrote: > > Finally! One of my top python wishes! > > Where can I vote? > > How can I get my hands on a back port? > > How can I help getting this sooner? > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/2QPAZ26E77MV2AZLDF3Z6DNHWZHQUPH5/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Kind regards, Stefano Borini ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/EEMTQCKZ7E62EYNV5S7CTLCJXBHFPBCM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Python standardization
Not sure about python, but throughout my career I had to work with MISRA C standardisation for critical systems. There is more and more that is handled by python that also needs to go through validation. I wonder if there's value in that? On Fri, 12 Feb 2021 at 18:40, Dan Stromberg wrote: > > > What would it take to create an ANSI, ECMA and/or ISO standard for Python? > > It seems to have really helped C. > > It looks like Java isn't standardized, and it's done OK, though perhaps it > was healthier in the past - before Oracle decided API's were ownable. > > I think standardizing Python might be really good for controlling its growth > and avoiding featuritis. > > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/JZYW4JOTANYIOLYDQ6YHRUP2TWO52OAE/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Kind regards, Stefano Borini ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/NR3UAEPEUJCWDBQVQW3QN4JYZWZNR2IU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 637 - Support for indexing with keyword arguments: request for feedback for SC submission
Yes. It's already supported in the branch. You can do MyType[whatever=5]. One could possibly change dict to allow both the specification dict[str, int] and dict[key=str, value=int], but this specific change of the dict class is not part of the implementation nor the PEP (nor I expect it to happen, for what matters, and I would not request it). On Sat, 6 Feb 2021 at 11:10, Larry Hastings wrote: > > > On 2/5/21 4:25 PM, Stefano Borini wrote: > > dicts and lists will keep working as before. They will not support > keyword arguments (probably ever, as there is no clear semantic for > them) and the current implementation simply throws an error if the > user tries to. > > > Is the plan to add PEP 637 support to type objects, so they allow > constructing type hints using named parameters, as suggested in the PEP? > > > Thanks, > > > /arry -- Kind regards, Stefano Borini ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/R2WISH5AJHNIUPVTFXFCTN7E2IIIBKHR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 637 - Support for indexing with keyword arguments: request for feedback for SC submission
On Sat, 6 Feb 2021 at 08:56, Batuhan Taskaya wrote: > > Lurking around the discussions I started to wonder whether this syntax > actually worths the burden it introduces. It has been discussed for weeks on py-ideas. > As you have commented out > earlier, there are no use cases in the built-in types, perhaps a > research would be great regarding possible use cases of keyword > arguments in and out of the stdlib. Nor there is for the @ operator, but it is still relevant for external libraries. > Now looking at PEP 637, even with > the theoretical examples given, it seems like we are introducing a > redundant syntax that has no other value than just complicating the > already complex subscript notation and becoming a bad alternative to > function call syntax. you can't do: f(x, y=3) = 5 but you can do a[x, y=3] = 5 pandas has relied on workarounds like iloc() to work around the lack of an indexing operator with keyword arguments, and we need them anyway for specifying types, now that the indexing operator is "abused of notation" all the time for typing. Of course the meaning of a[x, y=3] = 5 is up to the implementation of a. We don't prescribe anything on that. > > On Tue, Feb 2, 2021 at 2:40 PM Stefano Borini > wrote: > > > > Hi all, > > > > I would like to request feedback by python-dev on the current > > implementation of PEP 637 - Support for indexing with keyword > > arguments. > > > > https://www.python.org/dev/peps/pep-0637/ > > > > The PEP is ready for SC submission and it has a prototype > > implementation ready, available here (note, not reviewed, but > > apparently fully functional) > > > > https://github.com/python/cpython/compare/master...stefanoborini:PEP-637-implementation-attempt-2 > > > > (note: not sure if there's a preference for the link to be to the diff > > or to the branch, let me know if you prefer I change the PEP link) > > > > Thank you for your help. > > > > > > -- > > Kind regards, > > > > Stefano Borini > > ___ > > Python-Dev mailing list -- python-dev@python.org > > To unsubscribe send an email to python-dev-le...@python.org > > https://mail.python.org/mailman3/lists/python-dev.python.org/ > > Message archived at > > https://mail.python.org/archives/list/python-dev@python.org/message/E3AMOIB3GKYAGN6IVSLEEKVP4VUEC2V3/ > > Code of Conduct: http://python.org/psf/codeofconduct/ -- Kind regards, Stefano Borini ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/MX7YSGRP25KZ2LXW3CCQDRVAEKQ3WLNM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 637 - Support for indexing with keyword arguments: request for feedback for SC submission
dicts and lists will keep working as before. They will not support keyword arguments (probably ever, as there is no clear semantic for them) and the current implementation simply throws an error if the user tries to. Other classes will take advantage of the syntax for enhanced behavior. We are not specifying what that specific behavior might be (as in the case of the @ operator, which is "kind of bound" to a matmul operation, although it can be used for anything else, like / is used as a join operator in pathlib, even though its typical meaning is a division operator). Any class that is willing to accept keyword arguments for the indexing operation is responsible for documenting which arguments are accepted and what is the meaning of their use. We do not prescribe any rule, although some uses can probably be classified as bad practice. On Fri, 5 Feb 2021 at 10:30, Larry Hastings wrote: > > > I missed the discussion around the PEP. I don't mean to start another one, > I'd just like a clarification. The PEP describes the new functionality, and > the interfaces, and that's all fine. But I didn't see where it discussed > where this technology would be used. > > Would this mainly be used by third-party math libraries (Pandas, NumPy), like > the @ operator, or is there a plan to use this in Python's own library or > builtin objects? If the latter, can you go into the specifics? I'm guessing > the typing module would use it, as illustrated by one of the examples, but > beyond that I can't imagine how this would be used by e.g. dicts and lists. > > > Thanks, > > > /arry > > On 2/2/21 3:36 AM, Stefano Borini wrote: > > Hi all, > > I would like to request feedback by python-dev on the current > implementation of PEP 637 - Support for indexing with keyword > arguments. > > https://www.python.org/dev/peps/pep-0637/ > > The PEP is ready for SC submission and it has a prototype > implementation ready, available here (note, not reviewed, but > apparently fully functional) > > https://github.com/python/cpython/compare/master...stefanoborini:PEP-637-implementation-attempt-2 > > (note: not sure if there's a preference for the link to be to the diff > or to the branch, let me know if you prefer I change the PEP link) > > Thank you for your help. > > > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/TMAEJYBI7N73L64JPFODOGYD6KQY5PIH/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Kind regards, Stefano Borini ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LMAYSMML5QEEWROPEL52I43GB2DPWJMZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 637 - Support for indexing with keyword arguments: request for feedback for SC submission
On Thu, 4 Feb 2021 at 01:21, Petr Viktorin wrote: > The PEP does lack a "How to teach" section. I can add it tonight, and I think it would clarify some corner cases to make them more natural. Do you have something specific you are concerned about, when it comes to "teachability" (stress point, hard to grok, expected common mistakes)? I'd focus only on the use of the feature "from the outside", that is, using the indexing operation as a common user. For implementing the dunders, it's an advanced feature and it's unlikely to be discussed during basic teaching sessions. -- Kind regards, Stefano Borini ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/BJ5IT7T5RA6XFDZWTNIOPGLA6FSV35D2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] PEP 637 - Support for indexing with keyword arguments: request for feedback for SC submission
Hi all, I would like to request feedback by python-dev on the current implementation of PEP 637 - Support for indexing with keyword arguments. https://www.python.org/dev/peps/pep-0637/ The PEP is ready for SC submission and it has a prototype implementation ready, available here (note, not reviewed, but apparently fully functional) https://github.com/python/cpython/compare/master...stefanoborini:PEP-637-implementation-attempt-2 (note: not sure if there's a preference for the link to be to the diff or to the branch, let me know if you prefer I change the PEP link) Thank you for your help. -- Kind regards, Stefano Borini ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/E3AMOIB3GKYAGN6IVSLEEKVP4VUEC2V3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Modified parser does not seem to work. What am I doing wrong?
That's what I suspected looking at the parser debug in fact. Good to
see that I was on the right track. Thanks! I'll play with it a bit
more tonight.
On Fri, 16 Oct 2020 at 23:43, Pablo Galindo Salgado wrote:
>
> Hi Stefano,
>
> One of the problems you have is that the rule for slices has a negative
> lookahead for the comma:
>
> slices[expr_ty]:
> | a=slice !',' { a }
>
> IIRC the reason that is there is to allow "x[3,]" to be parsed.
>
> Also, to allow "a[k=3]" you need to to create a rule that allows skipping the
> "slices" part of the subscript and allow the 2nd argument of _Py_Subscript
> to be NULL. For example:
>
> | a=t_primary '[' k=kwargs ']' !t_lookahead { _Py_Subscript(a, NULL, k,
> Store, EXTRA) }
>
> Regards,
> Pablo
>
> On Fri, 16 Oct 2020 at 22:07, Stefano Borini wrote:
>>
>> Hello,
>>
>> I am trying to implement PEP-637, and I started modifying the parser
>> and the grammar, but I don't know what I am missing.
>>
>> The PR is here
>>
>> https://github.com/python/cpython/compare/master...stefanoborini:PEP-637-implementation-attempt-1?expand=1
>>
>> It includes other stuff but the core is that I extended the Subscript
>> in the asdl to accept the keyword args
>>
>> | Subscript(expr value, expr slice, keyword* keywords, expr_context ctx)
>>
>> which seems to work:
>>
>> >>> ast.parse('a[3]').body[0].value.keywords
>> []
>>
>> I also added a few "productions" (I believe they are called like this,
>> my compiler theory is very approximated), one of which is now
>>
>> primary[expr_ty]:
>>
>> | a=primary '[' b=slices c=[',' k=kwargs {k}]']' {
>> _Py_Subscript(a, b, c, Load, EXTRA) }
>>
>> I also tried with additional formats like
>>
>> | a=primary '[' b=slices c=kwargs ']' { _Py_Subscript(a, b, c,
>> Load, EXTRA) }
>>
>> or even just
>>
>> | a=primary '[' c=kwargs ']' { _Py_Subscript(a, NULL, c, Load, EXTRA) }
>>
>> but I always get a SyntaxError:
>>
>> >>> ast.parse('a[k=3]').body[0].value.keywords
>> Traceback (most recent call last):
>> File "", line 1, in
>> File "/Users/sbo/Work/Projects/stefanoborini/cpython/Lib/ast.py",
>> line 50, in parse
>> return compile(source, filename, mode, flags,
>> File "", line 1
>> a[k=3]
>>^
>> SyntaxError: invalid syntax
>>
>> Note that I always recreated ast parser and pegen.c with 'make
>> regen-all' and recompiled with make.
>> I tried to enable debug and print the pegen.c debug, but it's a bit
>> heavy and I could not immediately spot the issue. I suspect I am
>> missing something somewhere.
>>
>> Thanks
>>
>>
>> --
>> Kind regards,
>>
>> Stefano Borini
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/RZYDHYZPTPGLBX4VCR6HTYGJ3GL2CWIX/
>> Code of Conduct: http://python.org/psf/codeofconduct/
--
Kind regards,
Stefano Borini
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/266N3PGL4IXGVZB4QNQGR54DP5PHNABP/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Modified parser does not seem to work. What am I doing wrong?
Hello,
I am trying to implement PEP-637, and I started modifying the parser
and the grammar, but I don't know what I am missing.
The PR is here
https://github.com/python/cpython/compare/master...stefanoborini:PEP-637-implementation-attempt-1?expand=1
It includes other stuff but the core is that I extended the Subscript
in the asdl to accept the keyword args
| Subscript(expr value, expr slice, keyword* keywords, expr_context ctx)
which seems to work:
>>> ast.parse('a[3]').body[0].value.keywords
[]
I also added a few "productions" (I believe they are called like this,
my compiler theory is very approximated), one of which is now
primary[expr_ty]:
| a=primary '[' b=slices c=[',' k=kwargs {k}]']' {
_Py_Subscript(a, b, c, Load, EXTRA) }
I also tried with additional formats like
| a=primary '[' b=slices c=kwargs ']' { _Py_Subscript(a, b, c,
Load, EXTRA) }
or even just
| a=primary '[' c=kwargs ']' { _Py_Subscript(a, NULL, c, Load, EXTRA) }
but I always get a SyntaxError:
>>> ast.parse('a[k=3]').body[0].value.keywords
Traceback (most recent call last):
File "", line 1, in
File "/Users/sbo/Work/Projects/stefanoborini/cpython/Lib/ast.py",
line 50, in parse
return compile(source, filename, mode, flags,
File "", line 1
a[k=3]
^
SyntaxError: invalid syntax
Note that I always recreated ast parser and pegen.c with 'make
regen-all' and recompiled with make.
I tried to enable debug and print the pegen.c debug, but it's a bit
heavy and I could not immediately spot the issue. I suspect I am
missing something somewhere.
Thanks
--
Kind regards,
Stefano Borini
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/RZYDHYZPTPGLBX4VCR6HTYGJ3GL2CWIX/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Resurrecting PEP-472
First draft is available as a draft PR on https://github.com/python/peps/pull/1579 This draft contains just the motivation, not the implementation decisions. I'll add that in the upcoming nights, but it's now open for comments. On Mon, 31 Aug 2020 at 22:50, Stefano Borini wrote: > > On Sat, 29 Aug 2020 at 19:33, Antoine Pitrou wrote: > > > Agreed with Victor. Please create a new PEP. > > on it. > > -- > Kind regards, > > Stefano Borini -- Kind regards, Stefano Borini ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4VTPGPLTMR5ZUKQXDTCJEUYZAO7Y35SN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Resurrecting PEP-472
On Sat, 29 Aug 2020 at 19:33, Antoine Pitrou wrote: > Agreed with Victor. Please create a new PEP. on it. -- Kind regards, Stefano Borini ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KQQBVUPVDK6HGH3H23TOQIAB4MUXGA6U/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
On Thu, 16 Jul 2020 at 19:09, Richard Damon wrote:
> One question that comes to mind, does match NEED a colon at the end of it? If
> it didn’t have the colon, it wouldn’t need the indent for the following lines.
Or something like
match t case ("rect", real, imag):
return complex(real, imag)
case ("polar", r, phi):
return complex(r * cos(phi), r * sin(phi))
else:
pass
--
Kind regards,
Stefano Borini
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/G6HNAS4TMH6DY6QTAYXUZJK5GIRI3MC5/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
links to check out, with an > open mind. As a reminder, the introductory sections (Abstract, > Overview, and Rationale and Goals) have been entirely rewritten and > also serve as introduction and tutorial. > > - PEP 622: https://www.python.org/dev/peps/pep-0622/ > - Playground: > https://mybinder.org/v2/gh/gvanrossum/patma/master?urlpath=lab/tree/playground-622.ipynb > > -- > --Guido van Rossum (python.org/~guido) > Pronouns: he/him (why is my pronoun here?) > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/LOXEATGFKLYODO5Y4JLSLAFXKIAMJVK5/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Kind regards, Stefano Borini ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/TG64UO5WGOHTYQ5U46E3KFG4YKWQBARE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Cannot find documented API in PEP-376 (Database of Installed Python Distributions)
Hello, I am on a PEP scouting effort to check the current status of python packaging and its historical context, mostly for learning purposes. I noted that the PEP defines some functions for pkgutil (e.g. get_distributions), but I cannot find them. I tried to do some searching on the mailing list history, but I came up with pretty much nothing of value. It appears that the topic was last considered in 2009 (the year of the PEP). dist-info was then implemented, but I cannot find any information about the missing API, nor any additional PEP, except for a brief reference in PEP-427. Does anyone have some context for this? I understand it was 10 years ago, so it's mostly a curiosity. Thanks. -- Kind regards, Stefano Borini ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reject PEP 472: Support for indexing with keyword arguments
Hello, I am one of the authors of the PEP. I agree with your sentiment. I still think it might be useful in some contexts and I got some positive reactions here and there, but as you said it does not seem to provide a lot of added value. On Fri, 15 Mar 2019 at 21:50, Brett Cannon wrote: > The idea never seemed to gain any traction over its near 5 years in > existence as a PEP. > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/makepython%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why does python use relative instead of absolute path when calling LoadLibrary*
On 3/11/15 9:36 PM, David Cournapeau wrote: Hi, While looking at the import code of python for C extensions, I was wondering why we pass a relative path instead of an absolute path to LoadLibraryEx (see bottom for some context). In python 2.7, the full path existence was even checked before calling into LoadLibraryEx (https://github.com/python/cpython/blob/2.7/Python/dynload_win.c#L189), but it looks like this check was removed in python 3.x branch. Is there any defined behaviour that depends on this path to be relative ? My two cents. According to the MSDN documentation, passing a relative path is actually undefined https://msdn.microsoft.com/en-us/library/windows/desktop/ms684179%28v=vs.85%29.aspx LOAD_WITH_ALTERED_SEARCH_PATH 0x0008 If this value is used and lpFileName specifies an absolute path, the system uses the alternate file search strategy discussed in the Remarks section to find associated executable modules that the specified module causes to be loaded. If this value is used and lpFileName specifies a relative path, the behavior is undefined. --- meaning that wpathname _must_ be absolute. https://github.com/python/cpython/blob/master/Python/dynload_win.c#L222 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Problem displaying the warning symbol
Hi, I report a finding (bug?) about the warning unicode symbol, as reported here http://stackoverflow.com/questions/26919799/cannot-make-warning-sign-visible-on-osx-terminal In brief, python fails to correctly encode \u26a0 (warning sign) to utf-8, instead writing a space. It has no problems with other symbols. I m using python 3.4.0. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problem displaying the warning symbol
On 11/16/14 8:23 PM, Terry Reedy wrote: Stefano, the right place to send an enquiry about a bug is python-list, not py-dev. ok, sorry, but I wasn't even sure if it was a bug, and what was the root cause. I'm doubtful this is a Python problem though. More likely it is an issue with the curses library on OSX. Exactly. That's why I posted it here. I'll try to write it in C and see what happens. Presuming that the bytes are correct, there is no bug here. The bytes are correct, but if there's a problem in the osx curses lib, maybe a workaround is possible. I honestly don't understand the root cause at this point. However, let's close the conversation here, I will try to investigate a bit (if time allows) and if I find something conclusive I will either submit a patch or an investigation report. Thanks for the feedback. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
