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,
My question is simple: do we officially support Solaris and/or OpenIndiana?
Jesus Cea runs an OpenIndiana buildbot slave:
http://buildbot.python.org/all/buildslaves/cea-indiana-x86
"Open Indiana 32 bits"
The platform module of Python says "Solaris-2.11", I don't know the
exact OpenIndiana version.
A lot of unit tests fail on this buildbot with MemoryError. I guess
that it's related to Solaris which doesn't allow overcommit
(allocating more memory than available memory on the system), or more
simply because the slave has not enough memory.
There is now an issue which seems specific to OpenIndiana:
http://bugs.python.org/issue27847
It might impact Solaris as well, but the Solaris buildbot is offline
since "684 builds".
Five years ago, I reported a bug because the curses module of Python 3
doesn't build on Solaris nor OpenIndiana anymore. It seems like the
bug was not fixed, and the issue is still open:
http://bugs.python.org/issue13552
So my question is if we officially support Solaris and/or OpenIndiana.
If yes, how can we fix issues when we only have buildbot slave which
has memory errors, and no SSH access to this server?
Solaris doesn't seem to be officially supported in Python, so I
suggest to drop the OpenIndiana buildbot (which is failing since at
least 2 years) and close all Solaris issues as "WONTFIX".
Victor
Classes that doesn't define the __format__ method for custom PEP 3101
formatting inherits it from parents.
Originally the object.__format__ method was designed as [1]:
def __format__(self, format_spec):
return format(str(self), format_spec)
An instance is converted to string and resulting string is formatted
according to format specifier.
Later this design was reconsidered [2], and now object.__format__ is
equivalent to:
def __format__(self, format_spec):
assert format_spec == ''
return format(str(self), '')
Non-empty format specifier is rejected.
But why call format() on resulting string? Why not return resulting
string as is? object.__format__ could be simpler (not just
implementation, but for understanding):
def __format__(self, format_spec):
assert format_spec == ''
return str(self)
This can change the behaviour in corner case. str(self) can return not
exact string, but string subclass with overloaded __format__. But I
think we can ignore such subtle difference.
[1] https://www.python.org/dev/peps/pep-3101/
[2] http://bugs.python.org/issue7994
Hi all,
It's an old feature of the weakref API that you can define an
arbitrary callback to be invoked when the referenced object dies, and
that when this callback is invoked, it gets handed the weakref wrapper
object -- BUT, only after it's been cleared, so that the callback
can't access the originally referenced object. (I.e., this callback
will never raise: def callback(ref): assert ref() is None.)
AFAICT the original motivation for this seems was that if the weakref
callback could get at the object, then the weakref callback would
effectively be another finalizer like __del__, and finalizers and
reference cycles don't mix, so weakref callbacks can't be finalizers.
There's a long document from the 2.4 days about all the terrible
things that could happen if arbitrary code like callbacks could get
unfettered access to cyclic isolates at weakref cleanup time [1].
But that was 2.4. In the mean time, of course, PEP 442 fixed it so
that finalizers and weakrefs mix just fine. In fact, weakref callbacks
are now run *before* __del__ methods [2], so clearly it's now okay for
arbitrary code to touch the objects during that phase of the GC -- at
least in principle.
So what I'm wondering is, would anything terrible happen if we started
passing still-live weakrefs into weakref callbacks, and then clearing
them afterwards? (i.e. making step 1 of the PEP 442 cleanup order be
"run callbacks and then clear weakrefs", instead of the current "clear
weakrefs and then run callbacks"). I skimmed through the PEP 442
discussion, and AFAICT the rationale for keeping the old weakref
behavior was just that no-one could be bothered to mess with it [3].
[The motivation for my question is partly curiosity, and partly that
in the discussion about how to handle GC for async objects, it
occurred to me that it might be very nice if arbitrary classes that
needed access to the event loop during cleanup could do something like
def __init__(self, ...):
loop = asyncio.get_event_loop()
loop.gc_register(self)
# automatically called by the loop when I am GC'ed; async equivalent
of __del__
async def aclose(self):
...
Right now something *sort* of like this is possible but it requires a
much more cumbersome API, where every class would have to implement
logic to fetch a cleanup callback from the loop, store it, and then
call it from its __del__ method -- like how PEP 525 does it. Delaying
weakref clearing would make this simpler API possible.]
-n
[1] https://github.com/python/cpython/blob/master/Modules/gc_weakref.txt
[2] https://www.python.org/dev/peps/pep-0442/#id7
[3] https://mail.python.org/pipermail/python-dev/2013-May/126592.html
--
Nathaniel J. Smith -- https://vorpus.org
I've have just updated PEP 373 to say that Python 2.7.13 release
candidate 1 will be released on December 3. The final will follow two
weeks later on December 17. If there are delays in the process, the
final will likely to pushed into January.
Servus,
Benjamin
On 29.11.16 19:58, victor.stinner wrote:
> https://hg.python.org/cpython/rev/7efddbf1aa70
> changeset: 105395:7efddbf1aa70
> user: Victor Stinner <victor.stinner(a)gmail.com>
> date: Tue Nov 29 18:47:56 2016 +0100
> summary:
> Uniformize argument names of "call" functions
>
> * Callable object: callable, o, callable_object => func
> * Object for method calls: o => obj
> * Method name: name or nameid => method
This change looks wrong to me. "callable" and "callable_object" are
better names for functions like PyObject_Call(), since it supports not
just functions, but any callables. "name" is appropriate name of the
parameter that denotes a method name, not a method object.
Dear All,
While teaching Python protected variables, I figured out the oddity about
Python.
I am using Python 2.7.12+ for my teaching.
There is not really a concept of protected variables in Python, is it?
For a more detailed explanation of what I am trying to do, please read this
article, http://radek.io/2011/07/21/private-protected-and-public-in-python/
It that is the case, Python is not suitable for companies that require
secure transactions such as Banking softwares. What solution are possible
to overcome data masquerading attempts that might result because of this?
Thanks and regards,
Annapoornima
www.pyladies.co.in
Hello,
Escalating here an issue that seems that it should be tagged as blocker.
Currently the latest version of openssl-1.1.0c breaks Python's test suite.
The problematic commit was identified [0] and reverted [1] at openssl's upstream, however when running the test suite on a Fedora Rawhide machine, which includes the fix, the tests currently hang (not just failing like before).
The issue, with some more details, is tracked here: https://bugs.python.org/issue28689
[0] https://github.com/openssl/openssl/issues/1903
[1] https://github.com/openssl/openssl/commit/beacb0f0c1ae7b0542fe053b95307f5...
Regards,
Charalampos Stratakis
Associate Software Engineer
Python Maintenance Team, Red Hat
Because the deadline is imminent and because we have only received some
proposals, we will extend the current deadline. The new submission deadline is
2016-12-18.
Call For Proposals
==================
This is the official call for sessions for the Python devroom at FOSDEM 2017.
FOSDEM is the Free and Open source Software Developers' European Meeting, a free
and non-commercial two-day week-end that offers open source contributors a place
to meet, share ideas and collaborate.
It's the biggest event in Europe with +5000 hackers, +400 speakers.
For this edition, Python will be represented by its Community.
If you want to discuss with a lot of Python Users, it's the place to be!
Important dates
===============
* Submission deadlines: 2016-12-18
* Acceptance notifications: 2016-12-23
Practical
=========
* The duration for talks will be 30 minutes, including presentations and
questions and answers.
* Presentation can be recorded and streamed, sending your proposal implies
giving permission to be recorded.
* A mailing list for the Python devroom is available for discussions about
devroom organisation. You can register at this address:
https://lists.fosdem.org/listinfo/python-devroom
How to submit
=============
All submissions are made in the Pentabarf event planning tool at
https://penta.fosdem.org/submission/FOSDEM17
When submitting your talk in Pentabarf, make sure to select the Python devroom
as the Track.
Of course, if you already have a user account, please reuse it.
Questions
=========
Any questions, please send an email to info AT python-fosdem DOT org
Thank you for submitting your sessions and see you soon in Brussels to talk
about Python.
If you want to keep informed for this edition, you can follow our twitter
account @PythonFOSDEM.
* FOSDEM 2017: https://fosdem.org/2017
* Python Devroom: http://python-fosdem.org
* Twitter: https://twitter.com/PythonFOSDEM
Stephane
--
Stéphane Wirtel - http://wirtel.be - @matrixise
Hi,
I proposed a patch to drop the CALL_PROFILE special build to simplify
Python/ceval.c:
http://bugs.python.org/issue28799
I modified ceval.c for fast calls in Python 3.6, and I'm not sure that
the feature still works correctly. The feature is not well documented
and not tested at all.
For fast calls, I moved some code, so it's more complex to update call
statistics since statistics are implemented in ceval.c.
I would like to completely remove the feature to be able to implement
further optimizations.
Victor
