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'?
My question is simple: do we officially support Solaris and/or OpenIndiana?
Jesus Cea runs an OpenIndiana buildbot slave:
"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:
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:
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".
I've activated the webhook for receiving comments on issues when a commit
lands mentioning an issue, so if you see a commit from our hg integration
and another from GitHub, understand that's why (mention issues as "bpo
NNNN" in commit messages if you want to see it in action). If it becomes
too much of a hassle to see the duplicates before we migrate I can turn off
the notifications, but obviously more testing the better. :)
I recently refreshed regular expressions theoretical basics *indulging
in reminiscences* So, I read https://swtch.com/~rsc/regexp/regexp1.html
However, reaching the chart in the lower third of the article, I saw
Python 2.4 measured against a naive Thompson matching implementation.
And I was surprised about how bad it performed compared to an
unoptimized version of an older than dirt algorithm.
So, I decided to give it a try with Python2.7 and Python3.5. Eh, voilà,
100% cpu and no results so far. Nothing has changed at all since 2007.
>>> import re
>>> re.match(r'a?'*30 + r'a'*30, 'a'*30)
.... (still waiting)
Quoting from the article: " Some might argue that this test is unfair to
the backtracking implementations, since it focuses on an uncommon corner
case. This argument misses the point: given a choice between an
implementation with a predictable, consistent, fast running time on all
inputs or one that usually runs quickly but can take years of CPU time
(or more) on some inputs, the decision should be easy."
Victor, as the head of Python performance department, and Matthew, as
the maintainer of the new regex module, what is your stance on this
From my perspective, I can say, that regular expressions might worth
optimizing especially for web applications (url matching usually uses
regexes) but also for other applications where I've seen many tight
loops using regexes as well. So, I am probing interest on this topic here.
After reading Instagram's blog article , I’m thinking about how
Python can reduce memory usage of Web applications.
My company creating API server with Flask, SQLAlchemy and typing.
(sorry, it's closed source).
So I can get some data from it's codebase.
Report is here
My thoughts are:
* Interning (None,) seems worth enough.
* There are many empty dicts. Allocating ma_keys lazily may reduce
* Most large strings are docstring. Is it worth enough that option
for trim docstrings, without disabling asserts?
* typing may increase memory footprint, through functions
__attributes__ and abc.
* Can we add option to remove or lazy evaluate __attributes__ ?
* Using string literal for annotating generic type may reduce WeakRef usage.
* Since typing will be used very widely in this year. Need more
I am managing the team responsible for providing python packaging at
Enthought, and I would like to make sure we are providing a good (and
secure) out of the box experience for SSL.
My understanding is that PEP 476 is the latest PEP that concerns this
issue, and that PEP recommends using the system store:
https://www.python.org/dev/peps/pep-0476/#trust-database. But looking at
binary python distributions from python.org, that does not seem to a.ways
be the case. I looked at the following:
* 3.5.3 from python.org for OS X (64 bits): this uses the old, system
* 3.6.0 from python.org for OS X: this embeds a recent openssl, but ssl
seems to be configured to use non existing paths
(ssl..get_default_verify_paths()), and indeed, cert validation seems to
fail by default with those installers
* 3.6.0 from python.org for windows: I have not found how the ssl module
finds the certificate, but certification seems to work
Are there any official recommendations for downstream packagers beyond PEP
476 ? Is it "acceptable" for downstream packagers to patch python's default
cert locations ?
No Images? Click here
Glazing & Rainscreen Systems - Concept to Completion
ANGLIAN ARCHITECTURAL GLAZING & RAINSCREEN SYSTEMS
**FIRE RATED ALUMINIUM AND STEEL GLAZING SYSTEMS**
JANUARY HAS FLOWN BY...
...BUT YOU CAN BOOK THAT JOB IN WHILE WE'VE STILL GOT CAPACITY
Where has January gone to? Yes, we're now into the last week of the month and wish to say thanks to those clients who took up my offer to look at fast track work following my last email – we still have some immediate capacity at the present time but the 2017 order book is filling fast. So please keep those enquiries flowing - and existing customers - please don’t leave it till the last minute because we always want to say “YES WE CAN” to you especially !!
MTV Studios This month we feature more of our work in London - this time at MTV Studios in Camden, where we have installed curtain walling, complete with bris soleil and various feature cladding, as well as recreating and refurbishing feature elements from previous phases and a new rooflight. Good photographs have been difficult to source due to the extremely tight
nature of this site but we hope to get this job up on our website very soon - especially given the prestigious nature of the work carried out.
Portfolio Youcan see Anglian’s wide portfolio of work here on our website and we are happy to quote Aluminium Glazing and Rainscreen Systems projects from £100k to £2m value.
And finally, throughout 2017 please remember the website WWW.DIYROOFLIGHTS.COM
New customers are finding our SLIMGLAZE and SG2 Rooflights every month. We hope you will take a look because at £298 net ex works for a 1m x 1m double glazed stock unit they are competitively priced and available fast. We still believe that these are the BEST PRICES in the marketplace, but if you know otherwise, please let me know. Triple glazed Rooflights are also available and you can see the range of Rooflights here.
Please bookmark the website WWW.DIYROOFLIGHTS.COM for when you need it !
Best wishes for 2017 and we hope we can do business with you in this new year.
Ask Anglian! UK fabricators and installers that can manufacture bespoke solutions for refurbs and new builds, including curved head and fire rated windows.
Visit the website for more information.
Slimglaze and SG2 Rooflights
Anglian Architectural Slimglaze Rooflights are competitively priced and designed for installation on flat roofs. They come glazed and silicone sealed ready for installation.
Please follow this link for pricing and more information.
You can also see a number of Slimglaze examples here.
"ANGLIAN ARCHITECTURAL MANUFACTURE AND INSTALL FIRE RATED GLAZING SYSTEMS!!"
10 good reasons you should ask us to tender for your next project:
• Expert sub-contractor with big reputation for quality and efficiency
• Integrated capability includes design, surveying, manufacturing and installation
• Complete start-to-finish solution
• In-house design, fabrication and project management
• Critical product specification
• Problem solving
• Industry recognised systems and components
• All Quality Accreditations ISO 9001, ISO 14001, ISO 18001, CHAS
• Long experience working with major Contractors and High Street brands
• Competitive prices and value for money, guaranteed.
For more information please visit the website, phone 01485 520860
ANGLIAN ARCHITECTURAL LIMITED
Unit 1, Mill Lane, Waterford Industrial Est.
Gt. Massingham Norfolk PE32 2HT
Tel: 01485 520860 Fax: 01485 521196
Visit the Anglian Architectural website
Email for more information
Follow us on Twitter
Anglian Architectural are approved suppliers of Aluminium and Steel FIRE RATED GLAZING SYSTEMS and registered with Constructionline
Anglian Architectural Ltd, Unit 1 Mill Lane, Waterford Industrial Estate, Great Massingham, Norfolk PE32 2HT Company No: 04346652
Preferences | Unsubscribe
I just got burned (wasted a good day or so) by the fact that PyDateTimeAPI
wasn't initialized. The datetime.rst doc states (emphasis mine):
Before using any of these functions, the header file :file:`datetime.h`
must be included in your source (note that this is not included by
:file:`Python.h`), and the macro :c:macro:`PyDateTime_IMPORT` must be
invoked, *usually as part of the module initialisation function*.
I thought that surely the datetime module itself would initialize that
stuff. Why not? Is it so terribly expensive that the C API requires this
rather weird hack? The code's been their for ages, so there must have been
a good reason at one time. Is that reason still valid today? (I haven't
programmed at the C API level for a good long while, or I'm sure I'd have
encountered this before.)