On Mon, May 18, 2020 at 01:06:22PM -, James Lu wrote:
> "There should be one-- and preferably only one --obvious way to do it."
Yes?
"There should be one" does not mean the same thing as "there shouldn't
be two".
"There should be one qualified pilot in the cockpit of the plane at all
On Mon, May 18, 2020 at 11:25:39AM +0200, Alex Hall wrote:
> I understand this, but I still don't understand in what situation people
> use assertions 'correctly'.
https://import-that.dreamwidth.org/676.html
> To me an assert implies:
>
> 1. If the condition is false: that's bad, and the
The doc says "The following functions and classes are ported from the Python 2
module urllib (as opposed to urllib2). They might become deprecated at some
point in the future."
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe
Well it’s always possible that you’ll get an answer saying these should not
be deprecated. How can you be sure they were only kept for Py 2
compatibility?
On Mon, May 18, 2020 at 15:15 wrote:
> Thanks!
>
> I wasn't sure whether I was missing something as they were not deprecated
> at the same
Thanks!
I wasn't sure whether I was missing something as they were not deprecated at
the same time as URLOpener so I thought I would ask here before opening a
useless issue. Sorry for the noise if this not an appropriate usage of this
list.
___
Sounds eminently reasonable -- for this kind of stuff, why don't you open a
bpo issue?
On Mon, May 18, 2020 at 2:46 PM wrote:
> Both urlretrieve() and urlcleanup() were kept for backward compatibility
> with Python2 but they were never deprecated like urllib.request.URLOpener
> and
Both urlretrieve() and urlcleanup() were kept for backward compatibility with
Python2 but they were never deprecated like urllib.request.URLOpener and
urllib.request.FancyURLOpener.
Now that Python2 has been definitely sunset, can we raise a deprecation warning
so that they can be removed in
Certainly the way default arguments work with mutable types is not the most
intuitive and I think your complaint has some merit.
However how would you define the following to work:
def foo():
cons = [set(), [], (),]
funs = []
for ds in cons:
def g(arg:=ds):
return
On 5/18/20 9:06 AM, James Lu wrote:
> "There should be one-- and preferably only one --obvious way to do it."
*obvious*
multiple ways are allowed as long as there is one clear preference.
--
Richard Damon
___
Python-ideas mailing list --
"There should be one-- and preferably only one --obvious way to do it."
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
On 5/18/20 5:25 AM, Alex Hall wrote:
> On Mon, May 18, 2020 at 12:03 AM Richard Damon
> mailto:rich...@damon-family.org>> wrote:
>
> On 5/17/20 5:04 PM, Alex Hall wrote:
> > Some people (like myself, or the coworkers of [this
>
>
On 17/05/2020 19:43, David Mertz wrote:
I believe boolean mode switches are usually a bad design
for Python. Not always, there are exceptions like open().
Actually, open() is a really bad example. It does have a flag,
"closefd" which if False and a file descriptor was passed in rather than
On Mon, May 18, 2020 at 12:03 AM Richard Damon
wrote:
> On 5/17/20 5:04 PM, Alex Hall wrote:
> > Some people (like myself, or the coworkers of [this person](
> https://mail.python.org/archives/list/python-ideas@python.org/thread/PLXOXKACKGXN4ZKISDVXLKMFIETWTF63/))
> just like to use asserts as a
13 matches
Mail list logo
