just use
> https://www.boost.org/doc/libs/1_81_0/libs/python/doc/html/index.html
I would suggest taking a look at pybind11 for a potentially more modern
design (also, free of boost dependencies).
https://pybind11.readthedocs.io/en/latest/advanced/exceptions.html
Regards
Antoine.
__
hose developers are not so "young" for the most part :-)
Regards
Antoine.
___
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.pyth
Haven't we migrated to Discourse? This discussion will probably not
have any effects on this mailing-list.
(yes, not everyone likes Discourse, and I'm skeptical as well, but the
decision has been made by now)
On Mon, 17 Oct 2022 09:13:34 -
"Denis Kotov" wrote:
> Stephen J. Turnbull wrote:
rl has \p{HorizSpace} and \p{VertSpace}, so I'm going
> with that.
+1 for special Unicode categories rather than retargetting existing
escapes for something else.
(also, matching horizontal/vertical whitespace sounds rather unusual)
Regards
Antoine.
___
nd wouldn't want one. Gmane seems to
> have a complete archive that's searchable, regardless of "when I subscribed".
+1 as well (as in "that's what I do too").
Regards
Antoine.
___
Python-Dev mailing list -- pyth
Windows land with the godawful Windows.h
header file.
Regards
Antoine.
>
> But yes, it's going to be a complex transition.
>
>
> On Mon, May 30, 2022 at 12:30 PM Brett Cannon wrote:
>
> > We discussed having leading underscores for this API tier, and it was
On Mon, 16 May 2022 14:22:44 +0200
Victor Stinner wrote:
> On Mon, May 16, 2022 at 2:11 PM Antoine Pitrou wrote:
> > > PyUnicodeBuilder_Init(&builder);
> > >
> > > // Overallocation is more efficient if
iteStr(&builder, key);
> PyUnicodeBuilder_WriteChar(&builder, '=');
>
> // Disable overallocation before the last write
> PyUnicodeBuilder_DisableOverallocation(&builder);
Having to manually enable or disable overallocation doesn't sou
s it here first. Thoughts?
This seems like an attractive nuisance. Creating threads comes with its
own constraints and subtleties. I don't think it really helps users to
hide it behind a "regular" function call.
Like Greg I'm leaning towards -1 on this.
Regards
Antoine.
python/cpython/pull/92138
Doesn't passing "const PyObject*" leak implementation details, for
example that the reference count does not change? It seems to go
counter the objective of making the C API more abstract and more stable.
(C++ has the "mutable" keyword for such situat
thon/issues/83536
>
> In fact, after a long study, Python C API is *not* affected by this
> issue. Using "module" remains valid in C++20: see the issue for
> details.
I'm not surprised. The C++ committee takes compatibility extremely
seriously...
Regards
Antoine.
>
As a data point, I don't remember that recent versions of CPython
brought any particular pain for PyArrow, which is a set of bindings
written in Cython around some C++ core library code.
Regards
Antoine.
On Wed, 27 Apr 2022 18:31:13 +0200
Victor Stinner wrote:
> Hi,
>
> If
that would bring complication for no actual again
given that you're not likely to benefit from C++14 features in the
header files of a *C* project, are you?
Regards
Antoine.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscr
riable is an easy to influence a program or system
whose inner workings you don't control (for example a system that
spawns child Python processes). And it sounds like a good idea to allow
that given that it improves security?
Regards
Antoine.
>
> Victor
>
> On Wed, Apr 27,
On Tue, 26 Apr 2022 11:46:41 +0200
Victor Stinner wrote:
> I prefer to add an environment variable, only pass the option
> explicitly on the command line.
I don't really understand this sentence, can you rephrase?
___
Python-Dev mailing list -- pytho
On Wed, 20 Apr 2022 12:52:53 +0200
Victor Stinner wrote:
> On Wed, Apr 20, 2022 at 10:03 AM Antoine Pitrou wrote:
> > If the HPy design is the long term goal, why not just recommend that
> > people use HPy? And keep the C API for expert users with specific
> > needs tha
like we did with
`inspect.signature()`.
We also don't have to formally deprecate the older APIs, just recommend
the new one in the docs.
Regards
Antoine.
> Otherwise the way the stats result
> tuple works is a reasonable approach (and possibly deprecate indexed
> access?)
>
needs to be funded or supported by the PSF if it
doesn't advance fast enough)
Regards
Antoine.
>
> It will likely take multiple iterations (Python releases) to reach
> this goal, and incompatible C API changes may need a PEP (like PEP
> 674), but IMO it's good to keep this
ew Python releases. I check the bugs/PRs at least
> > every week and help wherever I can.
>
> Antoine is still active, so if he's fine with that, I'm also supportive.
> You're certainly familiar enough with that module.
I'm entirely su
not APIs, so the only reason to write a docstring is if
you want it to appear in test output. If you don't want it to appear
in test output, write a comment instead.
Regards
Antoine.
___
Python-Dev mailing list -- python-dev@python.org
To unsub
On Sat, 19 Feb 2022 12:05:22 -0500
Larry Hastings wrote:
> On 2/19/22 04:41, Antoine Pitrou wrote:
> > On Fri, 18 Feb 2022 14:56:10 -0700
> > Eric Snow wrote:
> >> On Wed, Feb 16, 2022 at 11:06 AM Larry Hastings
> >> wrote:
> >>> He suggested
antics, cutting down on the memory use of preforked server processes.
>
> Cool idea. I may mention it in the PEP as a possibility. Thanks!
That is not so cool if for some reason an application routinely loads
and unloads modules.
Regards
Antoine.
___
s maintain their own set of compatibility
wrappers and it makes sense to have an actively maintained project that
centralizes these.
Regards
Antoine.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python
ect_CallOneArg().
Regards
Antoine.
___
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
effects on the utilization of such internal structures (making
reference counting more costly than it appears to be), or on the
contrary whether the instructions in Py_INCREF were successfully
overlapped with other computations (making reference counting
practically free).
The only reliable way t
thon is an open source project, though.
And CPython probably supports more platforms than GHA or Azure do.
Regards
Antoine.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.pyth
also choose to rewrite its own
floating-point type from scratch, but that sounds unlikely.
Regards
Antoine.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python
Having some idea of what it actually gains us performance wise would be
> useful.
Exactly my sentiment. I'm also skeptical about the performance argument
in this case, but willing to be shown wrong :-)
Regards
Antoine.
>
> -gps
>
> On Mon, Feb 7, 2022 at 3:30 PM Brett Cannon wr
thon C
> API). Removing the structure from the public C API would solve the C++
> issue.
You could also have something like:
typedef struct {
PyObject_VAR_HEAD
Py_hash_t ob_shash;
#ifdef __cpluscplus
char ob_sval[1];
#else
char ob_sval[];
#endif
} PyBytesObject;
Regards
Antoine
On Tue, 18 Jan 2022 15:17:41 +0100
Victor Stinner wrote:
> Hi,
>
> My colleagues Tomáš Hrnčiar and Miro Hrončok made good progress on
> updating Python 3.10 to Python 3.11 in Fedora, but some specific
> Python 3.11 incompatible changes are causing more troubles than
> others:
> https://discuss.py
> discussion about it. See https://bugs.python.org/issue28739 for at least
> part of the discussion.
Ah, sorry for the misunderstanding. While the example I showed doesn't
have any substitutions, I'm interested in the non-trivial (non-constant)
case actually :-)
Regards
Antoine.
&
Hello,
Currently, a f-string is not recognized as a docstring:
>>> class C: f"foo"
>>> C.__doc__
>>>
This means you need to use a (admittedly easy) workaround:
>>> class C: __doc__ = f"foo"
>>> C.__doc__
'fo
ort for the next version
> of OpenSSL. I have shifted my personal OSS time to more fun topics like
> performance and WASM.
Sounds reasonable :-)
Out of curiosity, what are the performance regressions about?
Regards
Antoine.
___
Python-Dev maili
you might
want to re-run that one if you want a more rigorous confirmation that
there is no regression.
> my recommendation: proceed with removing 15-bit bignum digit support.
> 30-bit only future with simpler better code here we come.
Sounds reasonable to
the ABI issue. If you're able to dig up
> more information on that, I'd be interested to see it.
We don't have an ABI (except the stable ABI which doesn't expose object
internals), so this should be fine.
Regards
Antoine.
___
P
trings will also be *de facto* immortal, even if they are not
explicitly marked as such.
Regards
Antoine.
>
> Are you assuming that a change in one interpreter should not be seen by
> others? (Typical case, but not always true.)
>
> Or are you saying that there is a tech
On Thu, 16 Dec 2021 11:38:28 -0700
Eric Snow wrote:
> On Thu, Dec 16, 2021 at 4:34 AM Antoine Pitrou wrote:
> > As a data point, in PyArrow, we have a bunch of C++ code that interacts
> > with Python but doesn't belong in a particular Python module. That C++
> > code
On Thu, 16 Dec 2021 13:25:53 +0100
Petr Viktorin wrote:
> On 16. 12. 21 12:33, Antoine Pitrou wrote:
> > On Tue, 14 Dec 2021 10:38:25 -0700
> > Eric Snow wrote:
> >>
> >> So we (the core devs) would effectively be requiring those extensions
> >>
On Thu, 16 Dec 2021 23:32:17 +1100
Steven D'Aprano wrote:
> On Thu, Dec 16, 2021 at 12:23:09PM +0100, Antoine Pitrou wrote:
> >
> > The "real number of references" would not be known for immortal objects.
>
> Oh that surprises me. How does that work? Doe
On Tue, 14 Dec 2021 10:38:25 -0700
Eric Snow wrote:
>
> So we (the core devs) would effectively be requiring those extensions
> to support subinterpreters, regardless of letting them opt out. This
> situation has been weighing heavily on my mind since Nathaniel brought
> this up. Here are some
nyone actually does
> care (for whatever reason, good bad or indifferent) they can mask off
> the immortal bit to get the real ref num?
The "real number of references" would not be known for immortal objects.
Regards
Antoine.
___
Pytho
On Wed, 15 Dec 2021 14:13:03 +0100
Antoine Pitrou wrote:
> Hi Eric,
>
> Did you try to take into account the envisioned project for adding a
> "complete" GC and removing the GIL?
Sorry, I was misremembering the details. Sam Gross' proposal
(posted here on 07/1
Hi Eric,
Did you try to take into account the envisioned project for adding a
"complete" GC and removing the GIL?
Regards
Antoine.
On Tue, 14 Dec 2021 10:12:07 -0700
Eric Snow wrote:
> Hi all,
>
> I'm still hoping to land a per-interpreter GIL for 3.11. There is
ent threads at once, so might end up worse
performance-wise.
Regards
Antoine.
___
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/
t; rationale is strong enough.
> I believe we should:
> - Mark the l-value usage as deprecated in the docs,
> - And then do nothing until we find an actual case where this issue
> blocks development (or is actively dangerous for users).
Is there a way to emit a compilation warning when
not implemented?
IMHO at compile-time there's not much potential (for Python, which
doesn't have "true" constants). At run-time and based on
specialization, there could be.
Regards
Antoine.
>
> We already constant fold a variety of expressions
>
> 0 * 7
>
t I remember from the discussions at the time of PEP
3107. Annotations were purposefully use case-agnostic, and there was
no stated desire to push for one use case or another. I don't think
gradual typing was even on the radar, not in public comments anyway.
Regards
Antoine.
_
and I don't
> expect any difference between macros and static inline functions.
That would actually be interesting, since there can be surprises
sometimes with compilers... (function inlining depends on heuristics,
for example, and there may be positive or negative interactions
)
I think it's better that you contact the author upfront, asking for a
provisional agreement about stdlib inclusion. If he's not interested,
then no need to pursue it further. If he's interested, then you can
start working on a more formal proposal (for example a PEP).
Regards
A
Best regards
Antoine.
___
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/lis
veral*
sections exploring performance characteristics in several dimensions.
It is extremely rare for Python packages to provide such a detailed
insight on the matter (even the built-in `dict` is much less thoroughly
characterised).
http://www.grantjenks.com/docs/sortedcontainers/#user-guide
Regards
uthor) wants that too.
>
> It's first-rate code in all respects, including that it's a fine
> example _of_ Python programming (it's not written in C - in Python).
Agreed with Tim. This is a perfect example of some basic and perennial
facility that would f
act that the naming is confusing ("object copy to
object"?), it seems either PyBuffer_FromContiguous() or
PyBuffer_ToContiguous() should help implement similar functionality.
Regards
Antoine.
___
Python-Dev mailing list -- python-dev@python.
afe with macros should simply not use them.
This says that the idea is rejected, but it does not say *why* it was
rejected. Can you add that?
Regards
Antoine.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to pytho
xcept in Cython, but that's Cython's fault here)
Regards
Antoine.
___
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/
Me
fewer
> > situations than you'd expect.
>
> Maybe an alternate constructor could be added -- such as
> int.from_number() -- which would be restricted to calling __int__(),
> __index__(), and __trunc__().
Perhaps. And ideally there
d. The
code to make int(str) work is a separate code path inside
PyNumber_Long().
Note that PyNumber_Long() is now the only place inside the interpreter
calling the `nb_int` slot. But since it also has those undesirable code
paths accepting str and buffer-like objects, it's usable in fewer
situati
ent possibilites (including checks for str and buffer-like
objects, indeed).
Similarly:
>>> int(memoryview(b"123"))
123
>>> memoryview(b"123").__int__()
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'memoryview' obje
cally interchangeable?
Regards
Antoine.
___
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.pytho
n you're looking to efficiently handle large volumes of primitive
values such as integers, chances are Numpy already has the solution for
you.
Regards
Antoine.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email
e record:
"""
It’s harder to measure aggregate multi-threaded performance because
there aren’t any standard multi-threaded Python benchmarks, but the new
interpreter addresses many of the use cases that failed to scale
efficiently.
"&
ceptany" or "exceptall"?
Regards
Antoine.
___
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:/
On Mon, 4 Oct 2021 12:18:35 -0400
Calvin Spealman wrote:
> On Mon, Oct 4, 2021 at 12:07 PM Guido van Rossum wrote:
>
> > The question was about which style to *recommend* (a la PEP-8).
> >
>
> I think the very fact that it can't (or is difficult) be enforced,
How so? If style checkers are a
tionGroup
> instance under `e`.
+1. This is much more helpful to the reader than the cryptic
asterisk.
Regards
Antoine.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.
ll-maintained packages with lots of contributors get
frequent releases and keep up with the pace of changes in the packaging
ecosystem, but please don't forget that there's a long tail of packages
that are updated infrequently and but sti
On Tue, 28 Sep 2021 09:14:38 -0400
"Eric V. Smith" wrote:
> On 9/28/2021 9:10 AM, Antoine Pitrou wrote:
> > On Tue, 28 Sep 2021 08:55:05 -0400
> > "Eric V. Smith" wrote:
> >>> So I prefer to teach everybody how to use "-X frozen_modules=
ld be the point of printing a warning instead of doing just
what the user is expecting?
Freezing the stdlib is a startup performance optimization. It doesn't
need to be turned on when hacking on the Python source code... And
having to type "-X frozen_modules=off" is much mor
On Tue, 28 Sep 2021 10:51:53 +0200
Ronald Oussoren via Python-Dev wrote:
> > On 28 Sep 2021, at 10:05, Antoine Pitrou wrote:
> >
> > On Mon, 27 Sep 2021 10:51:43 -0600
> > Eric Snow > <mailto:ericsnowcurren...@gmail.com>> wrote:
> >> We've
the point of this thread.
>
> Possible solutions:
>
> 1. always default to "on" (the annoyance for contributors isn't big enough?)
> 2. default to "on" if it's a PGO build (and "off" otherwise)
> 3. default to "on&qu
he proposed function converts *from* an integer *to* a byte
"character". But the term character is a bit unfortunate here as well,
since characters in Python are Unicode.
Regards
Antoine.
___
Python-Dev mailing list -- python-dev
that `bytes.fromint` is a more comprehensible method name
> overall.
Perhaps we can call it `bytes.byte` to make it unambiguous?
Regards
Antoine.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to pytho
, to go the other direction
you need to walk the frames attached to the traceback. If there is no
frame on the traceback, you cannot go the other direction.
So a (fake or not) frame object is still desirable, IMHO.
Regards
Antoine.
___
Python-Dev m
arrangement for years has been to read most
open source mailing-lists using GMane, on a NNTP reader separate from my
main mail client. This works fine when I don't want to read open
source-related e-mails :-)
Regards
Antoine.
___
Python-Dev mai
On Sun, 22 Aug 2021 16:08:56 -0700
Guido van Rossum wrote:
> Hm, I don’t think the major use for bchr() will be with a constant.
What would be the major use for bchr()? I don't think I've ever
regretted its absence.
Regards
Antoine.
>
> On Sun, Aug 22, 2021 at 14:48 Greg
e 3,585
> list members that you're considering unsubscribing ;-)
Ok, let me announce that I don't consider unsubscribing because someone
made a mess of themselves in public. ;-)
Regards
Antoine.
___
Python-Dev mailing list -- python-dev@pytho
remove them in 3.13
>
> I personally agree with Irit, voting +1 for Option 3 since the old macros
> were soft-deprecated already by introducing new macros in 3.8, and more
> importantly made incompatible with pre-3.8 usage.
Agreed as well.
Regards
Antoine.
___
ool, nice and polite would be welcome here. Also an appeal to
think twice before posting... (is what you're going to say really going
to benefit the community?)
Regards
Antoine.
___
Python-Dev mailing list -- python-dev@python.org
To
ven if not so
> much for others.
In what context is `bchr()` useful?
Regards
Antoine.
___
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
On Tue, 29 Jun 2021 13:56:18 -0300
Joannah Nanjekye wrote:
> > why doesn't it get merged?
>
> The last significant discussion from a core dev on the most relevant PR
> here: https://github.com/python/cpython/pull/4819
> shows that Antoine was familiarizing himself w
e. something like "affected versions", "targeted
> versions", and "fixed versions". In any case, resolving the current ambiguity
> would be good and could also save triage and housekeeping work.
+1. "Affected versions" an
ompared to the Github user base,
python-dev is negligible).
Also, the python-dev community may always contemplate a move under a
different umbrella if necessary. Github won't change its umbrella to
just to make things easier for us.
Regards
Antoine.
_
tions to PEP 588's first
> open issue ("A GitHub account should not be a requirement"). Now would
> be the time to think about it, but I see no such reflection mentioned in
> the repo.
It's extremely unlikely that Github would allow participating on the
as.org/~strombrg/sort-comparison/
> > ...including a version of timsort that is in Cython or Pure Python.
> >
>
> Interesting! timsort get's to near-linear in your benchmark.
O(n log n) always looks linear when n is small enough...
Regards
Antoine.
__
On Thu, 13 May 2021 13:44:54 +0100
Steve Dower wrote:
> On 13May2021 1248, Petr Viktorin wrote:
> > On 13. 05. 21 11:45, Antoine Pitrou wrote:
> >>
> >> Le 13/05/2021 à 11:40, Irit Katriel a écrit :
> >>>
> >>>
> >>> On
Le 13/05/2021 à 11:40, Irit Katriel a écrit :
On Thu, May 13, 2021 at 10:28 AM Antoine Pitrou <mailto:anto...@python.org>> wrote:
I agree that is a reasonable spelling.
I initially suggested , but now I'm not sure because it
doesn't indicate what happens when y
there a convention on how such default sentinel values should appear in
> docs?
If this were a positional-only argument, you could use square brackets,
e.g.:
print_exception(exc[, value[, ...]])
Other than that, I can't think of any
x27;t know who "people" are in your sentence, but reviewing issues
and PRs generally requires a high familiarity with a project, and
enough confidence to speak with a voice of (seeming) authority. I'm
not convinced it's generally ea
t, someone thinks this enhancement makes sense.
> However, someone expressed opposition to this. So what is your opinion on
> this PR? Necessary or not? I want to hear more views on this. Thanks.
If it's only a matter of storage size, you can easily delete the
unwanted files. Is there a
is just a new convention.
>
> Test tools should treat DeprecationWarning as error by default [0][1].
> So even if end users don't really see it, I don't consider it "hidden".
Several data science libraries emit FutureWarning rather than
DeprecationWarning for the reason
th Pablo. Also, once we add a configuration option it becomes
delicate to later remove it.
Regards
Antoine.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailma
On Sun, 09 May 2021 02:16:02 -
"Jim J. Jewett" wrote:
> Antoine Pitrou wrote:
> > On Sat, 8 May 2021 02:58:40 +
> > Neil Schemenauer nas-pyt...@arctrix.com wrote:
>
> > > It would be cool if we could mmap the pyc files and have the VM run
lot of ideas)
But it would be weird to apply such level of engineering when we never
bothered compressing docstrings.
Regards
Antoine.
On Fri, 7 May 2021 23:30:46 +0100
Pablo Galindo Salgado wrote:
> This is actually a very good point. The only disadvantage is that it
> complicat
> >
>
>
> Is it really every instruction? Or only those that can raise exceptions?
I think almost any instruction can be interrupted with
KeyboardInterrupt (or any other asynchronously-raised exception).
Regards
Antoine.
___
Python-De
rger
> linenum/colnum tables. We would only load that data into memory if
> the table is accessed.
Memory-mapped files are accessed with page granularity (4 kB on x86), so
I'm not sure it's that simple. You would have to make sure to store
those tables in separa
yc files (why not), how about introducing a new version of the pyc
format with built-in LZ4 compression?
LZ4 decompression is extremely fast on modern CPUs (several GB/s) and
vendoring the C library should be simple.
https://github.com/lz4/lz4
Regards
Antoine.
__
emove bat [...]
> * Fix buffalo.spam [...]
>
> Function and class names should not be followed by parentheses,
> unless demonstrating an example call.
>
>
> Slapping my forehead,
You probably mean "Slap my forehead".
Regards
Antoine.
___
> Flags when no flags are set?
> >
> > What should we call it?
> >
> > - NONE
> >
> > - ZERO
> >
> > - EMPTY
> >
> > - ???
> >
> Definitely NONE. At some point I might even add it t
ting ~user/ on
> Windows, but on UNIX-oid it should not be deprecated IMO.
>
> (Spoken as an old UNIX nerd who's currently using Windows 10.)
Agreed with Guido.
Best regards
Antoine.
>
> On Wed, Apr 28, 2021 at 9:57 AM Senthil Kumaran wrote:
>
> > On Wed
d in those it doesn't seem to
fare that much better than Rust, either. But focussing on those two
languages shows a certain selection bias.
Regards
Antoine.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an ema
a S3 bucket.
For this reason, when there's no use case for accepting many kinds of
sequences in a user-facing API, I find it useful to do a `isinstance(x,
(list, tuple))` check before proceeding.
Yes, it's not pure duck typing, but who cares?
Regards
Antoine.
1 - 100 of 4917 matches
Mail list logo
