Re: [Python-ideas] Logical tracebacks

[Nathan Goldbaum]

This is a really great idea. I’d also point to the awful hacks that jinja2
needs to go through to elide jinia2 frames from user tracebacks as an
indicator that this is a desired feature.

https://github.com/pallets/jinja/blob/master/jinja2/debug.py

On Mon, Apr 15, 2019 at 2:08 PM Antoine Pitrou  wrote:

>
> Hello,
>
> I apologize because I'm only going to throw a very vague idea and I
> don't currently have time or motivation to explore it myself.  But I
> think it may prove interesting for other people and perhaps spur some
> concrete actionable proposal.
>
> With the growing complexity of Python software stacks, the length of
> tracebacks is continuously growing and is frequently making debugging
> errors and issues more tedious than it should be.  This is a
> language-agnostic problem.  Java software is often mocked for its
> ridiculously long tracebacks, but Python might come close in the future.
>
> Especially since Python is often the a language of choice for non
> computer science professionals, including but not only as a teaching
> language, this would be a problem worth solving.  We already recognized
> the issue some years ago, and even implemented a focussed fix for one
> specific context: the elision of importlib frames when an import error
> occurs:
> https://bugs.python.org/issue15110
>
> However, there are many contexts where implementation details would
> benefit from being hidden from tracebacks (the classical example being
> the internals of framework or middleware code, such as Django, Dask,
> etc.).  We would therefore have to define some kind of protocol by
> which tracebacks can be enumerated, not only as frames, but as logical
> execution blocks, comprised of one or several frames each, whose
> boundaries would reflect the boundaries of the various logical
> execution layers (again: framework, middleware...) involved in the
> frame stack.  We would probably also need some flag(s) to disable the
> feature in cases where the full stack frame is wanted (I imagine
> elaborate UIs could also allow switching back and forth from both
> representations).
>
> This would need a lot more thinking, and perhaps exploring what kind of
> hacks already exist in the wild to achieve similar functionality.
> Again, I'm just throwing this around for others to play with.
>
> Regards
>
> Antoine.
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add a __cite__ method for scientific packages

[Nathan Goldbaum]

On Thu, Jun 28, 2018 at 11:26 PM, Alex Walters 
wrote:

> But don't all the users who care about citing modules already use the
> scientific python packages, with scipy itself at it's center?  Wouldn't
> those engaging in science or in academia be better stewards of this than
> systems programmers?  Since you're not asking for anything that can't be
> done in a third party module, and there is a third party module that most
> of the target audience of this standard would already have, there is zero
> reason to take up four names in the python runtime to serve those users.
>


Not all scientific software in Python depends on scipy or even numpy.
However, it does all depend on Python.

Although perhaps that argues for a cross-language solution :)

I still think it would be very nice to have an official standard for
citation information in Python packages as codified in a PEP. That would
reduce ambiguity and make it much easier for tool-writers who want to parse
citation information.

> -Original Message-
> > From: Adrian Price-Whelan 
> > Sent: Friday, June 29, 2018 12:16 AM
> > To: Alex Walters 
> > Cc: Steven D'Aprano ; python-ideas@python.org
> > Subject: Re: [Python-ideas] Add a __cite__ method for scientific packages
> >
> > For me, it's about setting a standard that is endorsed by the
> > language, and setting expectations for users. There currently is no
> > standard, which is why packages use __citation__, __cite__,
> > __bibtex__, etc., and as a user I don't immediately know where to look
> > for citation information (without going to the source). My feeling is
> > that adopting __citation__ or some dunder name could be implemented on
> > classes, functions, etc. with less of a chance of naming conflicts,
> > but am open to discussion.
> >
> > I have some notes here about various ideas for more advanced
> > functionality that would support automatically keeping track of
> > citation information for imported packages, classes, functions:
> > https://github.com/adrn/CitationPEP/blob/master/NOTES.md
> >
> > On Thu, Jun 28, 2018 at 10:57 PM, Alex Walters 
> > wrote:
> > > Why not scipy.cite() or scipy.citation()?  I don't see any reason for
> these
> > > functions to ship with standard python at all.
> > >
> > >> -Original Message-
> > >> From: Python-ideas  > >> list=sdamon@python.org> On Behalf Of Steven D'Aprano
> > >> Sent: Thursday, June 28, 2018 8:17 PM
> > >> To: python-ideas@python.org
> > >> Subject: Re: [Python-ideas] Add a __cite__ method for scientific
> packages
> > >>
> > >> On Thu, Jun 28, 2018 at 05:25:00PM -0400, Andrei Kucharavy wrote:
> > >>
> > >> > As for the list, reserving a __citation__/__cite__ for packages at
> the
> > > same
> > >> > level as __version__ is now reserved and adding a citation()/cite()
> > >> > function to the standard library seemed large enough modifications
> to
> > >> > warrant searching a buy-in from the maintainers and the community at
> > >> large.
> > >>
> > >> I think that an approach similar to help/quit/exit is warranted. The
> > >> cite()/citation() function need not be *literally* built into the
> > >> language, it could be an external function written in Python and added
> > >> to builtins by the site.py module.
> > >>
> > >>
> > >>
> > >>
> > >> --
> > >> Steve
> > >> ___
> > >> Python-ideas mailing list
> > >> Python-ideas@python.org
> > >> https://mail.python.org/mailman/listinfo/python-ideas
> > >> Code of Conduct: http://python.org/psf/codeofconduct/
> > >
> > > ___
> > > Python-ideas mailing list
> > > Python-ideas@python.org
> > > https://mail.python.org/mailman/listinfo/python-ideas
> > > Code of Conduct: http://python.org/psf/codeofconduct/
> >
> >
> >
> > --
> > Adrian M. Price-Whelan
> > Lyman Spitzer, Jr. Postdoctoral Fellow
> > Princeton University
> > http://adrn.github.io
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add a __cite__ method for scientific packages

[Nathan Goldbaum]

This is an interesting proposal. Speaking as a developer of scientific
software packages it would be really cool to have support for something
like this in the language itself.

The software sustainability institute in the UK have written several blog
posts advocating the use of CITATION files containing this sort of metadata:

https://software.ac.uk/blog/2017-12-12-standard-format-citation-files

A github code search for __citation__ also gets 127 hits that mostly seem
to be research software that are using this attribute more or less as
suggested here:

https://github.com/search?q=__citation__=Code

It's also worth pointing out http://citeas.org/ which is sort of a citation
search engine for software projects. It uses a number of heuristics to
figure out what the appropriate citation for a piece of software is.

On Wed, Jun 27, 2018 at 5:49 PM, Guido van Rossum  wrote:

> While I'm not personally in need of citations (and never felt I was) I can
> easily understand the point -- sometimes citations can make or break a
> career and having written a popular software package should be acknowledged.
>
> Are there other languages or software communities that do something like
> this? It would be nice not to have to invent this wheel. Eventually a PEP
> and an implementation should be presented, but first the idea needs to be
> explored more.
>
> --Guido
>
> On Wed, Jun 27, 2018 at 3:30 PM Andrei Kucharavy <
> andrei.kuchar...@gmail.com> wrote:
>
>> Over the last 10 years, Python has slowly inched towards becoming the
>> most popular scientific computing language, beating or seriously
>> challenging Matlab, R, Mathematica and many specialized languages (S, SAS,
>> ...) in numerous applications.
>>
>> A large part of this growth is driven by amazing community packages, such
>> as numpy, scipy, scikits-learn, scikits-image, seaborn or pandas, just to
>> name a few. Development of such packages represents a significant time
>> investment by people working in academic environments. To be able to
>> justify the investment of time into such package development and support,
>> the developers usually associated them with a scientific article. The
>> number of citations of those articles are considered as measures of the
>> usefulness of articles and are required to justify the time spent on them.
>>
>> Unfortunately, as of now, a significant issue is that such packages are
>> not cited despite being extensively used. Part of this is due to the
>> difficulties with compiling the list of proper citations for each module
>> (and, for libraries associated with multiple update publications, selecting
>> the relevant citation). Part of this is due to users not realizing which of
>> the modules they are using have associated publications and should be cited.
>>
>> To remediate to that situation, I suggest a __citation__ method
>> associated to each package installation and import. Called from the
>> __main__, __citation__() would scan __citation__ of all imported packages
>> and return the list of all relevant top-level citations associated to the
>> packages.
>>
>> As a scientific package developer working in academia, the problem is
>> quite serious, and the solution seems relatively straightforward.
>>
>> What does Python core team think about addition and long-term maintenance
>> of such a feature to the import and setup mechanisms? What do other users
>> and scientific package developers think of such a mechanism for citations
>> retrieval?
>>
>> Best,
>>
>>
>> *Andrei Kucharavy*Post-Doc @ *Joel S. Bader*
>> * Lab*Johns Hopkins University, Baltimore, USA.
>>
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] An alternative to PEP 572's Statement-Local Name Bindings

[Nathan Goldbaum]

On Sat, Mar 3, 2018 at 5:12 AM Oleg Broytman  wrote:

> On Sat, Mar 03, 2018 at 02:36:39PM +1300, Greg Ewing <
> greg.ew...@canterbury.ac.nz> wrote:
> >[(f(y), g(y)) for x in things where y = h(x)]
> >
> > Possible objections to this:
> >
> > * Requires a new keyword, which may break existing code.
> >
> > - Yes, but "where" is an unlikely choice of name, being
> > neither a noun, verb or adjective, so it probably wouldn't
> > break very *much* code.
>
> ``where`` is a very popular name in code related to SQL. Take for
> example ORMs:
>
>
> https://github.com/sqlobject/sqlobject/search?l=Python=where==%E2%9C%93
>
>
> https://github.com/zzzeek/sqlalchemy/search?l=Python=where==%E2%9C%93
>

Where is also very common in numpy. So if someone did:

from numpy import *

data = where(condition)

They might have issues


> > --
> > Greg
>
> Oleg.
> --
>  Oleg Broytmanhttp://phdru.name/p...@phdru.name
>Programmers don't die, they just GOSUB without RETURN.
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Improve error message when missing 'self' in method definition

[Nathan Goldbaum]

Hi all,

Recently pypy received a patch that improves the error message one gets
when 'self' is missing in a method's signature:

https://mail.python.org/pipermail/pypy-dev/2016-September/014678.html

Here are the commits that implement the change in pypy:

https://bitbucket.org/pypy/pypy/commits/all?search=branch(better-error-missing-self)

I'm curious whether a similar improvement would also be received well in
CPython. In particular, this guides one to the correct solution for a
common programming mistake made by newcomers (and even not-so-newcomers).

Here is a case study that found this was a common source of errors for
newcomers:

http://dl.acm.org/citation.cfm?id=2960327

-Nathan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/