ANN: Python Meeting Düsseldorf - 02.07.2014
[This announcement is in German since it targets a local user group meeting in Düsseldorf, Germany] ANKÜNDIGUNG Python Meeting Düsseldorf http://pyddf.de/ Ein Treffen von Python Enthusiasten und Interessierten in ungezwungener Atmosphäre. Mittwoch, 02.07.2014, 18:00 Uhr Raum 1, 2.OG im Bürgerhaus Stadtteilzentrum Bilk Düsseldorfer Arcaden, Bachstr. 145, 40217 Düsseldorf Diese Nachricht ist auch online verfügbar: http://www.egenix.com/company/news/Python-Meeting-Duesseldorf-2014-07-02 NEUIGKEITEN * Bereits angemeldete Vorträge: Marc-Andre Lemburg "Python Web Installer Pakete - On-Demand Download bei der Installation" "Die neue Python Software Foundation (PSF)" Wir suchen noch weitere Vorträge. Bei Interesse, bitte unter i...@pyddf.de melden. * Startzeit und Ort: Dieses Mal treffen wir uns wieder 18:00 Uhr im Bürgerhaus in den Düsseldorfer Arcaden. Das Bürgerhaus teilt sich den Eingang mit dem Schwimmbad und befindet sich an der Seite der Tiefgarageneinfahrt der Düsseldorfer Arcaden. Über dem Eingang steht ein großes Schwimm'in Bilk Logo. Hinter der Tür direkt links zu den zwei Aufzügen, dann in den 2. Stock hochfahren. Der Eingang zum Raum 1 liegt direkt links, wenn man aus dem Aufzug kommt. Google Street View: http://bit.ly/11sCfiw EINLEITUNG Das Python Meeting Düsseldorf ist eine regelmäßige Veranstaltung in Düsseldorf, die sich an Python Begeisterte aus der Region wendet: * http://pyddf.de/ Einen guten Überblick über die Vorträge bietet unser YouTube-Kanal, auf dem wir die Vorträge nach den Meetings veröffentlichen: * http://www.youtube.com/pyddf/ Veranstaltet wird das Meeting von der eGenix.com GmbH, Langenfeld, in Zusammenarbeit mit Clark Consulting & Research, Düsseldorf: * http://www.egenix.com/ * http://www.clark-consulting.eu/ PROGRAMM Das Python Meeting Düsseldorf nutzt eine Mischung aus Open Space und Lightning Talks, wobei die Gewitter bei uns auch schon mal 20 Minuten dauern können ;-). Lightning Talks können vorher angemeldet werden, oder auch spontan während des Treffens eingebracht werden. Ein Beamer mit XGA Auflösung steht zur Verfügung. Folien bitte als PDF auf USB Stick mitbringen. Lightning Talk Anmeldung bitte formlos per EMail an i...@pyddf.de KOSTENBETEILIGUNG Das Python Meeting Düsseldorf wird von Python Nutzern für Python Nutzer veranstaltet. Um die Kosten zumindest teilweise zu refinanzieren, bitten wir die Teilnehmer um einen Beitrag in Höhe von EUR 10,00 inkl. 19% Mwst, Schüler und Studenten zahlen EUR 5,00 inkl. 19% Mwst. Wir möchten alle Teilnehmer bitten, den Betrag in bar mitzubringen. ANMELDUNG Da wir nur für ca. 20 Personen Sitzplätze haben, möchten wir bitten, sich per EMail anzumelden. Damit wird keine Verpflichtung eingegangen. Es erleichtert uns allerdings die Planung. Meeting Anmeldung bitte formlos per EMail an i...@pyddf.de WEITERE INFORMATIONEN Weitere Informationen finden Sie auf der Webseite des Meetings: http://pyddf.de/ Mit freundlichen Grüßen, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 23 2014) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2014-06-17: Released eGenix PyRun 2.0.0 ... http://egenix.com/go58 2014-07-02: Python Meeting Duesseldorf ... 9 days to go 2014-07-21: EuroPython 2014, Berlin, Germany ... 28 days to go eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ -- https://mail.python.org/mailman/listinfo/python-list
Re: [RELEASE] Nevow 0.11.1
- Original Message - > Hello, > > I'm pleased to announce the release of Nevow 0.11.1. > > Nevow is a web application construction kit written in Python and > based > on Twisted. It is designed to allow the programmer to express as much > of > the view logic as desired in Python, and includes a pure Python XML > expression syntax named stan to facilitate this. However it also > provides rich support for designer-edited templates, using a very > small > XML attribute language to provide bi-directional template > manipulation > capability. > > This release includes a number of minor new features and bug fixes. > It > also includes changes to modernize Nevow's packaging - installation > of > Nevow using `pip` is now supported. This release also marks the move > of > Nevow development to Github. > > You can read about all of the changes in this release in the NEWS > file: > >https://github.com/twisted/nevow/blob/release-0.11.1/NEWS.txt 404 not found https://github.com/twisted/nevow/blob/nevow-0.11.1/NEWS.txt cheers, JM -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- https://mail.python.org/mailman/listinfo/python-list
Re: old python
On Sun, 22 Jun 2014 13:18:09 -0700, arbautjc wrote:
> If anybody is interested...
>
> I think it's the same as the version unearthed recently [1], but here is
> a rather old version of Python on ftp:
>
> ftp://ftp.uni-duisburg.de/local/systems/unix/old_stuff/
>
>
> [1] http://legacy.python.org/download/releases/early/
It claims to be the same version, 0.9.1.
Among other differences, Python 0.9 doesn't accept "" as string
delimiters!
steve@runes:~/personal/python/python-0.9.1$ ./python0.9.1
>>> x = "hello"
Parsing error: file , line 1:
x = "hello"
^
Unhandled exception: run-time error: syntax error
>>> x = 'hello'
>>>
The exception system was primitive:
>>> 1/0
Unhandled exception: run-time error: integer division by zero
Stack backtrace (innermost last):
File "", line 1
>>>
There's no lambda built-in, but there is a version in the standard
library!
def lambda(args, expr):
if '\n' in args or '\n' in expr:
raise RuntimeError, 'lambda: no cheating!'
stmt = 'def func(' + args + '): return ' + expr + '\n'
print 'lambda:', stmt,
exec(stmt)
return func
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python ORM library for distributed mostly-read-only objects?
On Jun 23, 2014, at 12:26 AM, smur...@gmail.com wrote: > On Sunday, June 22, 2014 3:49:53 PM UTC+2, Roy Smith wrote: > >> Can you give us some more quantitative idea of your requirements? How >> many objects? How much total data is being stored? How many queries >> per second, and what is the acceptable latency for a query? > > Not yet, A whole lot, More than fits in memory, That depends. > > To explain. The data is a network of diverse related objects. I can keep the > most-used objects in memory but not all of them. Indeed, I _need_ to keep > them, otherwise this will be too slow, even when using Mongo instead of > SQLAlchemy. Which objects are "most-used" changes over time. > Are you sure it won’t fit in memory? Default server memory configs these days tend to start at 128 Gig, and scale to 256 or 384 Gig. -Bill > I could work with MongoEngine by judicious hacking (augment DocumentField > dereferencing with a local cache), but that leaves the update problem. > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Python ORM library for distributed mostly-read-only objects?
In article , William Ray Wing wrote: > On Jun 23, 2014, at 12:26 AM, smur...@gmail.com wrote: > > > On Sunday, June 22, 2014 3:49:53 PM UTC+2, Roy Smith wrote: > > > >> Can you give us some more quantitative idea of your requirements? How > >> many objects? How much total data is being stored? How many queries > >> per second, and what is the acceptable latency for a query? > > > > Not yet, A whole lot, More than fits in memory, That depends. > > > > To explain. The data is a network of diverse related objects. I can keep > > the most-used objects in memory but not all of them. Indeed, I _need_ to > > keep them, otherwise this will be too slow, even when using Mongo instead > > of SQLAlchemy. Which objects are "most-used" changes over time. > > > > Are you sure it won¹t fit in memory? Default server memory configs these > days tend to start at 128 Gig, and scale to 256 or 384 Gig. I'm not sure what "default" means, but it's certainly possible to get machines with that much RAM. On the other hand, even the amount of RAM on a single machine is not really a limit. There are very easy to use technologies these days (i.e. memcache) which let you build clusters to effectively aggregate the physical RAM from multiple machines. And database sharding lets you do a different flavor of memory aggregation. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python ORM library for distributed mostly-read-only objects?
On 22/06/14 10:46, smur...@gmail.com wrote: I've been doing this with a "classic" session-based SQLAlchemy ORM, approach, but that ends up way too slow and memory intense, as each thread gets its own copy of every object it needs. I don't want that. If you don't want each thread to have their own copy of the object, Don't use thread-scoped session. Use explicit scope instead. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python ORM library for distributed mostly-read-only objects?
Hi, William Ray Wing: > Are you sure it won’t fit in memory? Default server memory configs these > days tend to start at 128 Gig, and scale to 256 or 384 Gig. > I am not going to buy a new server. I can justify writing a lot of custom code for that kind of money. Besides, the time to actually load all the data into memory beforehand would be prohibitive (so I'd still need a way to load referred data on demand), and the update problem remains. -- -- Matthias Urlichs -- https://mail.python.org/mailman/listinfo/python-list
Re: Python ORM library for distributed mostly-read-only objects?
memcache (or redis or ...) would be an option. However, I'm not going to go through the network plus deserialization for every object, that'd be too slow - thus I'd still need a local cache - which needs to be invalidated. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python ORM library for distributed mostly-read-only objects?
On Monday, June 23, 2014 5:54:38 PM UTC+2, Lie Ryan wrote: > If you don't want each thread to have their own copy of the object, > > Don't use thread-scoped session. Use explicit scope instead. How would that work when multiple threads traverse the in-memory object structure and cause relationships to be loaded? IIRC sqlalchemy's sessions are not thread safe. -- https://mail.python.org/mailman/listinfo/python-list
Adding thread module support to Ubuntu 3 for Python3
What package do I need to install to get thread support (import thread) for Python 3 running under ubuntu 3? -- https://mail.python.org/mailman/listinfo/python-list
Re: Adding thread module support to Ubuntu 3 for Python3
On Monday, June 23, 2014 4:12:34 PM UTC-4, kena...@gmail.com wrote: > What package do I need to install to get thread support (import thread) for > Python 3 running under ubuntu 3? Found it. The import statement changed to "import _thread" for python3. -- https://mail.python.org/mailman/listinfo/python-list
Re: Adding thread module support to Ubuntu 3 for Python3
On Tue, Jun 24, 2014 at 6:34 AM, wrote: > On Monday, June 23, 2014 4:12:34 PM UTC-4, kena...@gmail.com wrote: >> What package do I need to install to get thread support (import thread) for >> Python 3 running under ubuntu 3? > > Found it. The import statement changed to "import _thread" for python3. Actually, that should give you a strong hint that you shouldn't be using that module. The leading underscore says that the module is private/internal. The thread module's docstring under Python 2 suggests that you should instead be using "import threading", which works on both versions. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python ORM library for distributed mostly-read-only objects?
On 23/06/14 19:05, smur...@gmail.com wrote: On Monday, June 23, 2014 5:54:38 PM UTC+2, Lie Ryan wrote: If you don't want each thread to have their own copy of the object, Don't use thread-scoped session. Use explicit scope instead. How would that work when multiple threads traverse the in-memory object structure and cause relationships to be loaded? IIRC sqlalchemy's sessions are not thread safe. You're going to have that problem anyway, if it is as you said that your problem is that you don't want each thread to have their own copy, then you cannot avoid having to deal with concurrent access. Note that SQLAlchemy objects can be used from multiple thread as long as it's not used concurrently and the underlying DBAPI is thread-safe (not all DBAPI supported by SQLAlchemy are thread safe). You can detach/expunge an SQLAlchemy object from the session to avoid unexpected loading of relationships. Alternatively, if you are not tied to SQLAlchemy nor SQL-based database, then you might want to check out ZODB's ZEO (http://www.zodb.org/en/latest/documentation/guide/zeo.html): > ZEO, Zope Enterprise Objects, extends the ZODB machinery to > provide access to objects over a network. ... ClientStorage > aggressively caches objects locally, so in order to avoid > using stale data the ZEO server sends an invalidation message > to all the connected ClientStorage instances on every write > operation. ... As a result, reads from the database are > far more frequent than writes, and ZEO is therefore better > suited for read-intensive applications. Warning: I had never used ZODB nor ZEO personally. -- https://mail.python.org/mailman/listinfo/python-list
Re: python 3.44 float addition bug?
It used to be that the best way to compare floating point numbers while disregarding the inherent epsilon was to use `str(x) == str(y)`. It looks like that workaround doesn't work anymore in 3.4. What's the recommended way to do this now? >>> format(.01 + .01 + .01 + .01 + .01 + .01, 'g') == format(.06, 'g') True On Saturday, June 21, 2014 12:24:24 PM UTC-7, Ned Deily wrote: > In article > > , > > Chris Angelico wrote: > > > Also, when you're looking at how things print out, consider looking at > > > two things: the str() and the repr(). Sometimes just "print(p)" > > > doesn't give you all the info, so you might instead want to write your > > > loop thus: > > > > > > z = 0.01 > > > p = 0.0 > > > for i in range(19): > > > p += z > > > print(str(p) + " -- " + repr(p)) > > > Sometimes you can get extra clues that way, although in this instance > > > I think you won't. > > > > Actually, I think this is one case where you would get extra clues (or > > extra headscratching) if you run the code with various releases of > > Python. > > > > $ python2.6 b.py > > 0.01 -- 0.01 > > 0.02 -- 0.02 > > 0.03 -- 0.02 > > 0.04 -- 0.040001 > > 0.05 -- 0.050003 > > 0.06 -- 0.060005 > > 0.07 -- 0.070007 > > 0.08 -- 0.080002 > > 0.09 -- 0.089997 > > 0.1 -- 0.02 > > 0.11 -- 0.10999 > > 0.12 -- 0.11998 > > 0.13 -- 0.12998 > > 0.14 -- 0.13999 > > 0.15 -- 0.14999 > > 0.16 -- 0.16 > > 0.17 -- 0.17001 > > 0.18 -- 0.18002 > > 0.19 -- 0.19003 > > > > $ python2.7 b.py > > 0.01 -- 0.01 > > 0.02 -- 0.02 > > 0.03 -- 0.03 > > 0.04 -- 0.04 > > 0.05 -- 0.05 > > 0.06 -- 0.060005 > > 0.07 -- 0.07 > > 0.08 -- 0.08 > > 0.09 -- 0.09 > > 0.1 -- 0.0 > > 0.11 -- 0.10999 > > 0.12 -- 0.11998 > > 0.13 -- 0.12998 > > 0.14 -- 0.13999 > > 0.15 -- 0.15 > > 0.16 -- 0.16 > > 0.17 -- 0.17 > > 0.18 -- 0.18002 > > 0.19 -- 0.19003 > > > > $ python3.4 b.py > > 0.01 -- 0.01 > > 0.02 -- 0.02 > > 0.03 -- 0.03 > > 0.04 -- 0.04 > > 0.05 -- 0.05 > > 0.060005 -- 0.060005 > > 0.07 -- 0.07 > > 0.08 -- 0.08 > > 0.09 -- 0.09 > > 0.0 -- 0.0 > > 0.10999 -- 0.10999 > > 0.11998 -- 0.11998 > > 0.12998 -- 0.12998 > > 0.13999 -- 0.13999 > > 0.15 -- 0.15 > > 0.16 -- 0.16 > > 0.17 -- 0.17 > > 0.18002 -- 0.18002 > > 0.19003 -- 0.19003 > > > > What's going on here is that in Python 2.7 the repr() of floats was > > changed to use the minimum number of digits to accurately roundtrip the > > number under correct rounding. For compatibility reasons, the str() > > representation was not changed for 2.7. But in Python 3.2, str() was > > changed to be identical to repr() for floats. It's important to keep in > > mind that the actual binary values stored in float objects are the same > > across all of these releases; only the representation of them as decimal > > characters varies. > > > > https://docs.python.org/2.7/whatsnew/2.7.html#other-language-changes > > > > http://bugs.python.org/issue9337 > > > > -- > > Ned Deily, > > n...@acm.org -- https://mail.python.org/mailman/listinfo/python-list
Off-Topic: The Machine
Following up on an earlier thread which started as a discussion on Apple's new language "Swift" and (d)evolved into a discussion about energy efficiency of computers, I came across this announcement of a new type of computer architecture invented by HP: "The Machine". http://www.iflscience.com/technology/new-type-computer-capable- calculating-640tbs-data-one-billionth-second-could Relevance: The Machine uses *eighty times less power* for the same amount of computing power as conventional architectures. If they could shrink it down to a mobile phone, your phone might last 2-3 months on a single charge. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Adding thread module support to Ubuntu 3 for Python3
On 06/23/2014 01:12 PM, kenak...@gmail.com wrote: What package do I need to install to get thread support (import thread) for Python 3 running under ubuntu 3? Just curious... Ubuntu 3 -- Are you really running a version that old, or is that a typo? Current version is 14.04 OT and FWIW: I gave up on Ubuntu when they switched to Unity -- I find that very awkward to use. Just personal opinion, of course, and I know there are others who like it -- that's fine with me as well. (But I switched to Mint.) -=- Larry -=- -- https://mail.python.org/mailman/listinfo/python-list
Re: Adding thread module support to Ubuntu 3 for Python3
On Tue, Jun 24, 2014 at 12:40 PM, Larry Hudson wrote: > OT and FWIW: I gave up on Ubuntu when they switched to Unity -- I find that > very awkward to use. Just personal opinion, of course, and I know there are > others who like it -- that's fine with me as well. (But I switched to > Mint.) Likewise, though with me it was Debian I went to, with Xfce as my desktop. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python 3.44 float addition bug?
On Tue, Jun 24, 2014 at 10:55 AM, buck wrote: > It used to be that the best way to compare floating point numbers while > disregarding the inherent epsilon was to use `str(x) == str(y)`. Who said that? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Ubuntu "3" (was Adding thread module support to Ubuntu 3 for Python3)
>> OT and FWIW: I gave up on Ubuntu when they switched to Unity -- I find that >> very awkward to use. Just personal opinion, of course, and I know there are >> others who like it -- that's fine with me as well. (But I switched to >> Mint.) > > Likewise, though with me it was Debian I went to, with Xfce as my desktop. > For me Lubuntu, which uses Ubuntu packages and a low-frills desktop interface. -- https://mail.python.org/mailman/listinfo/python-list
Re: python 3.44 float addition bug?
buck wrote: What's the recommended way to do this now? format(.01 + .01 + .01 + .01 + .01 + .01, 'g') == format(.06, 'g') There's no recommended way. What you're asking for can't be done. Whatever trick you come up with, there will be cases where it doesn't work. Why do you think you want to compare floats for equality? The best thing to do will depend on the answer to that. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: python 3.44 float addition bug?
On Mon, 23 Jun 2014 17:55:50 -0700, buck wrote: > It used to be that the best way to compare floating point numbers while > disregarding the inherent epsilon was to use `str(x) == str(y)`. It > looks like that workaround doesn't work anymore in 3.4. What inherent epsilon? Can you explain what you mean? > What's the recommended way to do this now? > format(.01 + .01 + .01 + .01 + .01 + .01, 'g') == format(.06, 'g') > True That's equivalent to doing an implicit round. If all you want to do is round your calculations, then explicitly round them: py> x = sum([0.01]*6) py> y = 0.06 py> round(x, 12) == round(y, 12) True Not that I'm recommending that you do it this way, but an explicit round is better than using string formatting. See also this: http://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/ -- Steven -- https://mail.python.org/mailman/listinfo/python-list
