Hi, all.
To avoid BytesWarning, the compiler needs to do some hack when they
need to store bytes and str constants in one dict or set.
BytesWarning has maintenance costs. It is not huge, but significant.
When can we remove it? My idea is:
3.10: Deprecate the -b option.
3.11: Make the -b option n
Woah, this is both exciting and scary. If adopted, it will be a major
change to how Python programs are written. It seems a lot of work has
been put into polishing the design. That's good because if we do this,
will not be easy to fix things later if we made design errors.
One of my first t
On 10/23/20 4:50 PM, Steven D'Aprano wrote:
On Fri, Oct 23, 2020 at 01:06:36PM -0700, Ethan Furman wrote:
I think having a *fail* keyword for unit testing
would be great.
Luckily, we already have it:
assert False
I take it you don't run your unit tests under -O :-)
`raise Exception`
On Fri, Oct 23, 2020 at 01:06:36PM -0700, Ethan Furman wrote:
> >I think having a *fail* keyword for unit testing
> >would be great.
>
> Luckily, we already have it:
>
> assert False
I take it you don't run your unit tests under -O :-)
`raise Exception` works fine for me.
--
Steve
On 24/10/20 7:52 am, Umair Ashraf wrote:
class MyTest(unittest.TestCase):
def test_this_and_that(self):
"""
Given inputs
When action is done
Then it should pass
"""
fail
def fail():
raise Exception("It didn't work!")
Not every one-line function
On 10/23/20 11:52 AM, Umair Ashraf wrote:
Hello
Howdy!
Can I suggest a feature to discuss and hopefully develop and send a PR.
You can, but the place to do it is Python Ideas:
https://mail.python.org/mailman3/lists/python-ideas.python.org/
python-id...@python.org
I think having
I do not understand how a simple raise is worse than this. A simple variable
holding some standard error (like test not implemented error) should be no
different. (like fail = NotImplementedError("Test has not been implemented yet")
I feel like this is a useless syntactic sugar but if you give s
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 input
On Fri, Oct 23, 2020 at 6:19 AM Tin Tvrtković wrote:
> Hi,
>
> first of all, I'm a big fan of the changes being proposed here since in my
> code I prefer the 'union' style of logic over the OO style.
>
> I was curious, though, if there are any plans for the match operator to
> support async stuff
ACTIVITY SUMMARY (2020-10-16 - 2020-10-23)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7608 (-99)
closed 46258 (+176)
total 53866 (+77)
Open issues
Hi,
first of all, I'm a big fan of the changes being proposed here since in my
code I prefer the 'union' style of logic over the OO style.
I was curious, though, if there are any plans for the match operator to
support async stuff. I'm interested in the problem of waiting on multiple
asyncio task
11 matches
Mail list logo
