[Python-Dev] Re: _PyBytesWriter/_PyUnicodeWriter could be faster
Thanks for your very informative reply.
I replied you in issue41486. Maybe memory blocks will not bring performance
improvement to _PyBytesWriter/_PyUnicodeWriter, which is a bit frustrating.
> For a+b, Python first computes "a", then "b", and finally "a+b". I don't see
> how your API could optimize such code.
I mean this situation:
s = 'a' * 100_000_000 + '\uABCD'
b = s.encode('utf-8')
b.encode('utf-8') # <- this situation
I realize I was wrong, the UCS1->UCS2 transformation will only be done once, it
only saves a memcpy().
Even in this case it will only save two memcpy():
s = 'a' * 100_000_000 + '\uABCD' * 100_000_000 + '\U00012345'
b = s.encode('utf-8')
b.encode('utf-8')
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/KFSOMXABV3OHLL3MW3MULYONVIP6O2WT/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Macro for logging
Thank you Victor, I know. I meant a macro in CPython. Maybe not so sane to have a unique global logger in C, as Antoine pointed out. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/V4VHKYVDJQ354MVQSJJLBQKJSLV6HOCR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Macro for logging
21.10.20 15:30, Antoine Pitrou пише: > On Wed, 21 Oct 2020 14:19:37 +0200 > Marco Sulla wrote: >> If not already present, do you think it's useful to add a macro that does >> something like >> >> # ifdef Py_DEBUG >> fprintf(stderr, "%s\n", message); >> # endif > > In general, you want to do this on a per-component basis, so each C > source file tends to redefine its own macros if it needs to. I concur with Antoine. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/GKP52NSQEE4I4JVC7LVEO2LQISCVXFO3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: fail keyword like there is pass keyword
Hello,
In the context of pattern matching, not accepting a match
subject that does not match any of the case clauses is
probably going to be frequent if not the most frequent.
Thus, when PEP 634, 635, 636 are -- hopefully -- accepted,
and experience with the feature is gained, this idea might
be worth reconsidering, allowing the rewrite of something like
https://github.com/gvanrossum/patma/blob/master/examples/over.py#L57-L68
```
match args:
case [Point2d(x, y)]:
return Point3d(x, y, 0)
case [p := Point3d()]:
return p
case [x := int(), y := int()]:
return Point3d(x, y, 0)
case [x := int(), y := int(), z := int()]:
return Point3d(x, y, z)
case _:
raise TypeError("Huh?")
```
into
```
match args:
case [Point2d(x, y)]:
...
case ...:
...
case ...:
...
case ...:
...
case _:
impossible
```
where `impossible` raises AssertionError.
Best regards,
Jean Abou-Samra
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/3D6TDUJ4V3Q6DF3UCSBUF7ETGYAG46AJ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: fail keyword like there is pass keyword
On Wed, Oct 28, 2020 at 6:49 AM Jean Abou Samra wrote: > where `impossible` raises AssertionError. > Reserving a common English word as a new keyword (whether fail or impossible) is the mother of all breaking changes. The syntactic sugar it provides is not only tiny, it's pretty much negative, since any message it could provide would be too generic to be of much use, versus raising your own relevant exception message. -Em ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/ONEKNUWIPL2QHA4K5JY4CFKHPU7FJ4HI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: fail keyword like there is pass keyword
On Wed, Oct 28, 2020 at 12:48 PM Emily Bowman wrote: > On Wed, Oct 28, 2020 at 6:49 AM Jean Abou Samra > wrote: > >> where `impossible` raises AssertionError. >> > > Reserving a common English word as a new keyword (whether fail or > impossible) is the mother of all breaking changes. The syntactic sugar it > provides is not only tiny, it's pretty much negative, since any message it > could provide would be too generic to be of much use, versus raising your > own relevant exception message. > Indeed, especially when you can write this once at the top of your module, or in a utils module in a larger package: def unreachable(): raise AssertionError and then Jean's example can be spelled: match args: case [Point2d(x, y)]: ... case ...: ... case ...: ... case ...: ... case _: unreachable() Same benefit of a plain English word, identical behavior, very very tiny downside of two parentheses and a two-line function definition, and zero breakage or compatibility issues. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/YNUJL3BUA7Z2UNQ7ECITTYEKX6U7SUQA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Steering Council Election Timeline for 2021 term
Hi! The timeline for this year's election will be the same as last year. * The nomination period will begin Nov 1, 2020 (do not post nominations until then) * Nomination period will end Nov 15, 2020 * Voting will begin Dec 1, 2020 * Voting will end Dec 15, 2020 Nominations will be collected via https://discuss.python.org/ (more details to follow on Nov 1). New for this year: Ernest W. Durbin III will be running the vote along with the assistance of Joe Carey, a PSF employee. They will be co-admins going forward. I have cc'ed them in on this thread as well in case there are any questions. Thanks, Ewa ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/JHYSU6FEYM3A5AZXSICO5OE3VAWDPGEJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: fail keyword like there is pass keyword
Homonyms are words spelled the same way with different meanings, like bat (flying mammal) and bat (club used to hit a baseball) (btw, club (a blunt instrument) and club (a closed association of people))... In 22 years of programming Python, I always understood the "pass" keyword as "to forgo an opportunity to act". Of course, I also use "pass" as the opposite of "fail" in tests, but that was never the meaning of the *pass keyword* for me. Anyway, I subscribe 100% to Emily Bowman's position: "Reserving a common English word as a new keyword (whether fail or impossible) is the mother of all breaking changes." And the benefit is negative. Cheers, Luciano On Fri, Oct 23, 2020 at 4:42 PM Umair Ashraf wrote: > Hello > > Can I suggest a feature to discuss and hopefully develop and send a PR. I > think having a *fail* keyword for unit testing would be great. So we > write a test as follows which will fail to begin with. > > class MyTest(unittest.TestCase): >def test_this_and_that(self): > """ > Given inputs > When action is done > Then it should pass > """ > fail > > This keyword is to fill an empty function block like *pass* but this will > make the function raise an exception that test is failing. I know there is > *raise* but I feel this *fail* keyword is needed to write a test first > which fails and then write code and then come back to the test and fill its > body. > > Umair > > -- > > ___ > Python-Dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/QPOVO34K63CLEY66GSY5JOLWBRG5QRUM/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Technical Principal at ThoughtWorks | Twitter: @ramalhoorg ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/KV7HDSQKSIGZHTUVPTKTMDNIN6CKVWNE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Accepting PEP 626
On behalf of the steering council, I am happy to announce that as BDFL-Delegate I am accepting PEP 626 -- Precise line numbers for debugging and other tools. I am confident this PEP will result in a better experience for debuggers, profilers and tools that rely on tracing functions. All the existing concerns regarding out-of-process debuggers and profilers have been addressed by Mark in the latest version of the PEP. The acceptance of the PEP comes with the following requests: * The PEP must be updated to explicitly state that the API functions described in the "Out of process debuggers and profilers" must remain self-contained in any potential future modifications or enhancements. * The PEP states that the "f_lineno" attribute of the code object will be updated to point to the current line being executed even if tracing is off. Also, there were some folks concerned with possible performance implications. Although in my view there is no reason to think this will impact performance negatively, I would like us to confirm that indeed this is the case before merging the implementation (with the pyperformance test suite, for example). Congratulations Mark Shannon! Thanks also to everyone else who provided feedback on this PEP! Regards from rainy London, Pablo Galindo Salgado ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/5ETSBH4GP2UAJTAIQ575DHCUA35H64IR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: os.scandir bug in Windows?
On 10/28/20, Stephen J. Turnbull wrote: > > Note: you can "fix" directory updates by mounting the filesystem r/o. Mounting the filesystem as readonly is the extreme case. Popular Unix systems support a "noatime" mount option that disables updating file access times, unless one of the other timestamps changes. In Windows, NTFS and ReFS support a system setting (but not per-volume) to disable updating access times -- "NtfsDisableLastAccessUpdate" and "RefsDisableLastAccessUpdate". ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/E5AWEB3U5ZCQBWABOKAGL6CADRHBLEEP/ Code of Conduct: http://python.org/psf/codeofconduct/
