[Python-Dev] Re: The current state of typing PEPs
So maybe this is my time to chime in. I have used annotations for runtime behavior. My primary use case is an injection library that I wrote. It allows something along the lines of: class IMyService(IService): pass @inject def call_something(arg1: str, arg2: int, svc: IMyService = None): assert svc is not None # do stuff... At runtime the `inject()` decorator will scan the function signature and insert an instance of `IMyService` based on a registry lookup. (We use zope.component utilities, but that's an implementation detail.) When testing, one can simply pass a mock version of the service. Using the mypy-zope plugin, the above also passes all mypy type checking. It is a simple pattern in terms of annotation but a very effective pattern that mimics other injection systems in Java and TypeScript (Angular). We have used it for a few years now and like it a lot. Regards, Stephan On Monday, November 29, 2021 6:00:04 PM EST Barry Warsaw wrote: > On Nov 26, 2021, at 01:13, Paul Moore wrote: > > I'd therefore interpret Barry's plea as being for *anyone* with a use > > for annotations to provide their feedback (at least, anyone who > > accepts that annotations are types), with particular emphasis on > > people who want to use the types declared in annotations to affect > > runtime behaviour, as that's the most under-represented group at the > > moment (and it's not clear whether it's under-represented because > > there aren't many such uses, or because the users aren't being heard > > from). > > Spot on. > > -Barry -- Stephan Richter Entrepreneur & Geek ___ 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/list/python-dev@python.org/message/XRJJ4ZMOQJXOTRFT3FQ25QXHXOKBVXKP/ Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-Dev] #Python3 ! ? (was Python Library Support in 3.x)
On Monday, June 21, 2010, Nick Coghlan wrote: > A decent listing of major packages that already support Python 3 would > be very handy for the new Python2orPython3 page I created on the wiki, > and easier to keep up-to-date. (the old Early2to3Migrations page > didn't look particularly up to date, but hopefully we can keep the new > list in a happier state). I really just want to be able to go to PyPI, Click on "Browse packages" and then select "Python 3" (it can currently be accomplished by clicking "Python" and then "3"). Of course, package developers need to be encouraged to add these Trove classifiers so that the listings are as complete as possible. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter" ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] #Python3 ! ? (was Python Library Support in 3.x)
On Monday, June 21, 2010, Barry Warsaw wrote: > On Jun 21, 2010, at 11:13 AM, Stephan Richter wrote: > >I really just want to be able to go to PyPI, Click on "Browse packages" > >and then select "Python 3" (it can currently be accomplished by clicking > >"Python" and then "3"). Of course, package developers need to be > >encouraged to add these Trove classifiers so that the listings are as > >complete as possible. > > Trove classifiers are not particularly user friendly. I wonder if we can > help with a (partially) automated or guided tool to help? Maybe something > on the web page for packages w/o classifications, kind of like a Linked-in > progress meter... Yeah that would be good. I thought the "Score" was something like that, but it is not transparent enough. It would be great, if PyPI would tell me how I can improve my package meta-data. (The Linked-in progress meter worked for me too. ;-) Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter" ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Zope-dev] Syntax error in python2.6
On Monday 21 July 2008, Tino Wildenhain wrote: > btw, shouldn't this already give a warning in 2.5? It does. I see it. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
On Thursday, December 08, 2011 01:18:06 AM Benjamin Peterson wrote: > > Right.. the title does say "readd ... support in 3.3". Are you > > suggesting "the ship has sailed" for eternity because it can't be > > supported in Python < 3.3? > > I'm questioning the real utility of it. The real utility is to make it possible to port libraries to Py3 or at least make it a lot easier. It is somewhat naive to think that you can just tell everyone to upgrade to Python 2.7 and then use the future import. Having to change all that code can also be a big bug magnet. Chris has been a great champion of bringing the Web app community closer to Python 3. His experience with porting code is pretty extensive especially in keeping it compatible with older Pythonn 2 versions (down to 2.5). If the Python Devs want more adoption of Python 3, they should at least throw a bone from time to time and make adoption a bit easier. The arguments against this proposal seem academic and purist to me. (Mmh, I cannot believe I just wrote that having been accused of that myself in the past.) Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter" ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
On Thursday, December 08, 2011 01:08:31 PM Łukasz Langa wrote: > A big bug magnet is using a Python version that is not getting any fixes > whatsoever. When I'm backporting stuff from Python 3, I'm targeting 2.6+ > because it's still somewhat supported by us. What's more important though > is that there were tremendous changes in that release in terms of bridging > the gap between Python 2 and 3. But you might not have that luxury and updating code to a new Python version is a lot of work. As you can see in my signature, I am very much involved in the Zope community. The entire Zope, Plone and Pyramid ecosystem is extremely large and one can simply not make blanket statements about Python version use. We try very hard to move our libraries up the version ladder but we must also take great care of backwards-compatibility. (We have seen already what happens if we do not with Zoep 2 versus 3. And Python is struggling with similar issues, even though the changes were much less drastic.) Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter" ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] @deprecated (was: Useful thread project for 2.5?)
On Tuesday 08 March 2005 18:05, Jim Jewett wrote:
> ... compiler recognition of "@deprecated" in doc comments.
>
> Michael Chermside suggested:
>
> = code =
> import warnings
>
> def deprecated(func):
> """This is a decorator which can be used to mark functions
> as deprecated. It will result in a warning being emmitted
> when the function is used."""
> def newFunc(*args, **kwargs):
> warnings.warn("Call to deprecated function.")
> return func(*args, **kwargs)
> return newFunc
>
> = example =
> ...
> UserWarning: Call to deprecated function.
This is a recipe for disaster. Creating a new function from the old can have
unwanted side effects, since you effectively change the object. For example,
if someone is monkey patching this function, then the deprecation warning
gets lost.
In Zope 3's deprecation package, we have decided to put a special deprecation
proxy around the module (instead of the function) and register a list of
attribute names (note that it does not matter whether its a class, function
or other type of object) that are deprecated. The advantage is that you get a
deprecation warning just by looking up the object.
See: http://svn.zope.org/Zope3/trunk/src/zope/deprecation/
Disclaimer: This code is a bit experimental and might not be the best
solution. It is currently used in the trunk and does a pretty good job,
though.
Regards,
Stephan
--
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] @deprecated (was: Useful thread project for 2.5?)
On Tuesday 08 March 2005 18:05, Jim Jewett wrote:
> ... compiler recognition of "@deprecated" in doc comments.
>
> Michael Chermside suggested:
>
> = code =
> import warnings
>
> def deprecated(func):
> """This is a decorator which can be used to mark functions
> as deprecated. It will result in a warning being emmitted
> when the function is used."""
> def newFunc(*args, **kwargs):
> warnings.warn("Call to deprecated function.")
> return func(*args, **kwargs)
> return newFunc
>
> = example
This is a recipe for disaster. Creating a new function from the old can have
unwanted side effects, since you effectively change the object. For example,
if someone is monkey patching this function, then the deprecation warning
gets lost.
In Zope 3's deprecation package, we have decided to put a special deprecation
proxy around the module (instead of the function) and register a list of
attribute names (note that it does not matter whether its a class, function
or other type of object) that are deprecated. The advantage is that you get a
deprecation warning just by looking up the object.
See: http://svn.zope.org/Zope3/trunk/src/zope/deprecation/
Disclaimer: This code is a bit experimental and might not be the best
solution. It is currently used in the trunk and does a pretty good job,
though.
Regards,
Stephan
--
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PSF grant / contacts
On Tuesday 09 August 2005 09:05, Greg Wilson wrote: > I'm working with support from the Python Software Foundation to develop an > open source course on basic software development skills for people with > backgrounds in science and engineering. I have a beta version of the > course notes ready for review, and would like to pull in Python-friendly > people in sci&eng to look it over and give me feedback. If you know > people who fit this bill (particularly people who might be interested in > following along with a trial run of the course this fall), I'd be grateful > for pointers. Yeah, I would be interested. I have taught my fellow grad students last semester Python, but the docs out there were not that good for teaching scientific data analysis. I am planning to repeat the course with Physics undergrad students this Fall. If you could send me the material, I would appreciate it. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Divorcing str and unicode (no more implicit conversions).
On Sunday 23 October 2005 18:10, Jason Orendorff wrote: > -1 on keeping the source encoding of string literals. Python should > definitely decode them at compile time. > > -1 on decoding implicitly "as needed". This causes decoding to happen > late, in unpredictable places. Decodes can fail; they should happen > as early and as close to the data source as possible. +1. We have followed this last practice throughout Zope 3 successfully. In our case, the publisher framework (in other words the output-protocol-specific layer) is responsible for the decoding and encoding of input and output streams, respectively. We have been pretty much free of any encoding/decoding troubles since. Having our application only use unicode internally was one of the best decisions we have made. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Naming conventions in Py3K
On Friday 30 December 2005 06:10, Ka-Ping Yee wrote: > > In fact, I like it that the basic Python functions > > I didn't say anything about renaming functions. Functions in lowercase > are one of the naming conventions that Python does follow consistently. well, it is not consistent when looking at functions versus methods. The best example here is hasattr() versus dict.has_key(). Overall I agree with your proposal to use a consistent naming style. Whatever it may turn out to be. We have done the same when we started with Zope 3 and while having some few inconsistencies, the overall code base benefitted a lot, I think. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
