[if this isn't the correct spot, let me know and I'll gladly take it elsewhere]
I have found myself needing powerset functionality several times
recently to the point where I wondered if there's interest in making
it part of the standard library. I have a working implementation and
tests. Would take but 3 minutes to add it in and issue a pull request,
but I'd like to know if there's interest from esteemed group members.
Thanks for the quick turnaround. -- H
If you wish to request my time, please do so using bit.ly/hd1AppointmentRequest.
Si vous voudrais faire connnaisance, allez a bit.ly/hd1AppointmentRequest.
Sent from my mobile device
Envoye de mon portable
I'd like to use the re module to parse a long text file, 1GB in size. I
wish that the re module could parse a stream, so I wouldn't have to load
the whole thing into memory. I'd like to iterate over matches from the
stream without keeping the old matches and input in RAM.
What do you think?
Since __fspath__ was introduced in PEP 519 it is possible to create
object classes that are representing file system paths.
But there is no corresponding type object in the "typing" module. Thus I
cannot specify functions, that accept any kind of object which supports
the __fspath__ protocol.
Please note that "Path" is not a replacement for "SupportsFsPath", since
the concept of PEP 519 is, that I could implement new objects (without
dependency to "Path")
that are implementing the __fspath__ protocol.
On 7 Oct 2018 20:39, "Michael Selik" <mike(a)selik.org> wrote:
Isn't there some rule about noticing an undocumented feature, like,
whoever pours the last cup of coffee needs to brew a fresh pot? :-)
Most of the credit belongs, I think, to the original poster. His statement,
that Python wasn't very Pythonic here, really drew attention to the empty
> Date: Sun, 23 Sep 2018 07:09:37 +0200
> From: Marko Ristin-Kaufmann <marko.ristin(a)gmail.com>
> To: Python-Ideas <python-ideas(a)python.org>
> Subject: [Python-ideas] Why is design-by-contracts not widely adopted?
[ munch ]
> *. *After properly reading about design-by-contract and getting deeper into
> the topic, there is no rational argument against it and the benefits are
> obvious. And still, people just wave their hand and continue without
> formalizing the contracts in the code and keep on writing them in the
Firstly, I see a difference between rational arguments against Design By
Contract (DbC) and against DbC in Python. Rejecting DbC for Python is
not the same as rejecting DbC entirely.
Programming languages are different, obviously. Python is not the same
as C is not the same as Lisp... To me this also means that different
languages are used for different problem domains, and in different styles
of development. I wouldn't use DbC in programming C or assembler
because it's not really helpful for the kind of low level close to the machine
stuff I use C or assembler for. And I wouldn't use DbC for Python because
I wouldn't find it helpful for the kind of dynamic, exploratory development
I do in Python. I don't write strict contracts for Python code because in a
dynamically typed, and duck typed, programming language they just don't
make sense to me. Which is not to say I think Design by Contract is bad,
just that it isn't good for Python.
Secondly, these "obvious" benefits. If they're obvious, I want to know why
aren't you using Eiffel? It's a programming language designed around DbC
concepts. It's been around for three decades, at least as long as Python or
longer. There's an existing base of compilers and support tools and libraries
and textbooks and experienced programmers to work with.
Could it be that Python has better libraries, is faster to develop for, attracts
more programmers? If so, I suggest it's worth considering that this might
be *because* Python doesn't have DbC.
Or is this an updated version of the old saying "real programmers write
FORTRAN in any language" ? If you are accustomed to Design by Contract,
think of your time in the Python world as a trip to another country. Relax
and try to program like the locals do. You might enjoy it.
I think that a time decorator will be a useful addition to the sandard library, as i find the current way of measuring execution time a bit tedious:
timeit.timeit("fun_to_time(a, b)", setup="from __main__ import a, b", number=1)
def fun_to_time(a, b):
I already made a basic implementation of it, and it's working well.
When trying to import lzma on one of my machines, I was suprised to get
a normal import error like for any other module. According to the docs
lzma has been part of stdlib since 3.3. Further digging revealed that
the error is due to the fact that xz wasn't compiled in when building
Python. Since I suspect that there are other optional stdlib modules,
this made me think whether the message in those cases should look a
little more polished. Perhaps installing a stub module that prints some
informative text before raising the relevant exception or similar.
Also, maybe add a little note in the docs, stating that despite being
part of stdlib this module might not be available on all systems.
This thread is about debugging. I suggest we start by collecting
problems and possible solutions. And that after about a week of that,
we start discussing what we've gathered.
We already have a problem and possible solution, provided by Eric
Smith and Larry Hastings.
TITLE: f-string "debug" conversion
print('value = ', value)
is tedious, particularly for more complicated expressions, such as
print('big_array[5:20] =', big_array[5:20])
For f-strings, we add a !d conversion operator, which produces the
text of an expression followed by its value. Thus, the two previous
examples can be written more concisely as
I suggest for the moment that we just gather problem-solution pairs,
much as above. I think they'll be between 5 and 15 such pairs. I'll
post one to the current discussion thread in an hour or so.
And that after about a week, we move to discussing what we have.
Finally, many thanks to Eric and Larry for their useful contribution
to the important problem of debugging.
I'm working on decorators that have a dynamic __doc__ property computed at
runtime and not at decoration time.
The decorator must return the wrapper as a function and can not return a
callable object with __call__ since the "self" argument would not be
properly passed through the decorator. (Making __call__ a static method
drops implicitly the first argument). If __call__ could be a static method
and get the arguments as-are, I could make __doc__ a property. But this is
not possible, right?
Assigning a class satisfying the property protocol to the function
wrapper.__doc__ did not work either since the property object is returned
as-is instead of invoking __get__ on it.
Could someone explain a bit -- is this the desired behavior or a bug or an
Is there any way for a callable object to be used as a decorator?