webmaster has already heard from 4 people who cannot install it.
I sent them to the bug tracker or to python-list but they seem
not to have gone either place. Is there some guide I should be
sending them to, 'how to debug installation problems'?
Laura
Hi everyone,
Something occurred to me while trying to analyze code today: profiler and
cProfiler emit their data in pstats format, which various tools and
libraries consume. tracemalloc, on the other hand, uses a completely
separate format which nonetheless contains similar data. In fact, in many
non-Python applications I've worked in, heap and CPU profiles were always
emitted in identical formats, which allowed things like visual
representations of stack traces where memory is allocated, and these have
proven quite useful in practice and allowed lots of sharing of tools across
many applications.
Is there a particular design reason why these formats are different in
Python right now? Would it make sense to consider allowing them to match,
e.g. having a tracemalloc.dump_pstats() method?
Yonatan
Hi friends,
I am meanwhile the PySide maintainer at The Qt Company,
and we are trying to make the mapping from Qt functions
to Python functions as comparable as possible.
One problem are primitive pointer variables:
In Qt, it is natural to use "sometype *varname" to make a
mutable variable. In Python, you have to turn such a thing
into a result-tuple. Example:
void QPrinter::getPageMargins(qreal *left, qreal *top, \
qreal *right, qreal *bottom, QPrinter::Unit unit) const
(meanwhile deprecated, but a good example)
is mapped to the Python signature
def getPageMargins(self, \
unit: PySide2.QtPrintSupport.QPrinter.Unit) \
-> typing.Tuple[float, float, float, float]: ...
NOW my question:
----------------
I would like to retain the variable names in Python!
The first idea is to use typing.NamedTuple, but I get the impression
that this would be too much, because I would not only need to create
an extra named tuple definition for every set of names, but also
invent a name for that named tuple.
What I would like to have is something that looks like
def getPageMargins(self, \
unit: PySide2.QtPrintSupport.QPrinter.Unit) \
-> typing.NamedTuple[left: float, top: float, \
right:float, bottom:float]: ...
but that is obviously not a named tuple.
Possible would be to derive a name from the function, so maybe
a definition could be used like
class PageMargingResult(NamedTuple):
left: float
top: float
right: float
bottom: float
but then I would have some opaque PageMargingResult type. This would
work, but as said, this is a bit too much, since I only
wanted something like a tuple with names.
What do you suggest to do here? Something what I am missing?
Cheers -- Chris
--
Christian Tismer :^) tismer(a)stackless.com
Software Consulting : http://www.stackless.com/
Karl-Liebknecht-Str. 121 : https://github.com/PySide
14482 Potsdam : GPG key -> 0xFB7BEE0E
phone +49 173 24 18 776 fax +49 (30) 700143-0023
I thought that the name in a module is in the public interface if:
* It doesn't start with an underscore and the module does not have __all__.
* It is included in the module's __all__ list.
* It is explicitly documented as a part of the public interface.
help() uses more complex rules, but it believes __all__ if it defined.
But seems there are different views on this.
* Raymond suggested to add an underscore the two dozens of names in the
calendar module not included in __all__.
https://bugs.python.org/issue28292#msg347758
I do not like this idea, because it looks like a code churn and makes
the code less readable.
* Gregory suggests to document codecs.escape_decode() despite it is not
included in __all__.
https://bugs.python.org/issue30588
I do not like this idea, because this function always was internal, its
only purpose was implementing the "string-escape" codec which was
removed in Python 3 (for reasons). In Python 3 it is only used for
supporting the old pickle protocol 0.
Could we strictly define what is considered a public module interface in
Python?
Hi!
During the sprints after EuroPython, I made an attempt at adding support for
comparing the results from `.values()` of two dicts.
Currently the following works as expected:
```
d = {'a': 1234}
d.keys() == d.keys()
d.items() == d.items()
```
but `d.values() == d.values()` does not return the expected
results. It always returns `False`. The symmetry is a bit off.
In the bug trackers[0] and the Github PR[1], I was asked
to raise the issue on the python-dev mailing list to find
a consensus on what comparing `.values()` should do.
I'd argue that Python should compare the values as expected here,
or if we don't want to encourage that behaviour, maybe we should
consider raising an exception.
Returning just `False` seems a bit misleading.
What are your thoughts on the issue?
Best regards,
Kristian Klette
[0]: https://bugs.python.org/issue37585
[1]: https://github.com/python/cpython/pull/14737
This time without delays, I present you Python 3.8.0b3:
https://www.python.org/downloads/release/python-380b3/ <https://www.python.org/downloads/release/python-380b3/>
This release is the third of four planned beta release previews. Beta release previews are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. The next pre-release of Python 3.8 will be 3.8.0b4, the last beta release, currently scheduled for 2019-08-26.
Call to action
We strongly encourage maintainers of third-party Python projects to test with 3.8 during the beta phase and report issues found to the Python bug tracker <https://bugs.python.org/> as soon as possible. While the release is planned to be feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (2019-09-30). Our goal is have no ABI changes after beta 3 and no code changes after 3.8.0rc1, the release candidate. To achieve that, it will be extremely important to get as much exposure for 3.8 as possible during the beta phase.
Please keep in mind that this is a preview release and its use is not recommended for production environments.
Last beta coming
Beta 4 can only be released if all “Release blocker” and “Deferred blocker” issues on bugs.python.org <http://bugs.python.org/> for 3.8.0 are resolved. Please prioritize those for the next four weeks.
Acknowledgements
Thanks to our binary builders, Ned and Steve, who were very quick today to get the macOS and Windows installers ready. The Windows story in particular got pretty magical, it’s now really fully automatic end-to-end.
Thanks to Victor for vastly improving the reliability of multiprocessing tests since Beta 2.
Thanks to Pablo for keeping the buildbots green.
- Ł
🍝 copy-pasta from core-mentorship mailing list.
There is now a “newcomer friendly” keyword in bpo.
My hope is that going forward, we can tag issues that are suitable for
first time contributors with this keyword.
It would be great for experienced contributors already familiar with our
workflow to not work on issues tagged with newcomer friendly and leave that
to new contributors.
I’ve added the keyword to Devguide’s Triaging section, with additional
guideline of what can be tagged as newcomer friendly. Typically it should
be straightforward, well-defined issue, and low-risk.
https://devguide.python.org/triaging.html#keywords
Thanks.
ᐧ
On Thu, Jul 25, 2019 at 4:35 AM Petr Viktorin <encukou(a)gmail.com> wrote:
> It's not the equality operator that errors: `==` means element-wise
> comparison in Numpy. The error would come from a conversion of the array
> to bool:
>
> >>> numpy.array([1, 2, 3]) == numpy.array([1, 3, 4])
> array([ True, False, False])
>
> >>> if numpy.array([ True, False, False]):
> ... print('Same!')
> ...
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> ValueError: The truth value of an array with more than one element is
> ambiguous. Use a.any() or a.all()
>
This is true of course. I was being overly concise, but `arr1 == arr2`
does not itself (currently) raise any exception. It's only `if arr1==arr2`
that does.
But what NumPy does is return a "special" object that has some methods to
convert it into a boolean in different ways. We COULD do that with
`d1.values() == d2.values()` in principle. This "DictValuesComparison"
object could have methods like `.equal_as_set()` and `.equal_as_list()`.
However, that's a lot of machinery for very little gain.
In contrast, a NumPy boolean array is useful for lots of purposes, and it
is something we want independently to have around. Mostly it's a great way
of indexing into another list of numeric elements. But it also can be used
in some less common, but not uncommon ways. A hypothetical
DictValuesComparison object would have nearly no use other than avoiding
wrapping d.values() in list(), which we can already do fine. Sure, maybe
that rare case could be made a little faster with this custom machinery,
but it doesn't feel worthwhile to me.
Therefore, I think the exception with guidance in the message should happen
at actual equality (or inequality) comparison time, not when casting to a
boolean context.
Numpy currently returns False when `==` “doesn't make sense”, but
> apparently has plans to change that:
>
> >>> numpy.array([1, 2, 3]) == numpy.array([1, 2])
> __main__:1: DeprecationWarning: elementwise comparison failed; this will
> raise an error in the future.
> False
>
> >>> numpy.array([1, 2, 3]) == numpy.array(['a', 'b'])
> __main__:1: FutureWarning: elementwise comparison failed; returning
> scalar instead, but in the future will perform elementwise comparison
> False
>
This is very interesting! I did not know about this planned change. That
NumPy will start raising exceptions on equality comparison adds a little
bit of support for my suggestion, I think.
> > So, a helpful error message including something like "Cannot compare
> > dict.values directly, consider converting to sets / lists / sorted
> > lists before comparing" ?
>
--
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons. Intellectual property is
to the 21st century what the slave trade was to the 16th.
