Re: [Python-Dev] Proposal: add odict to collections
Armin Ronacher active-4.com> writes: > > There are far more responses for that topic than I imagined so I would love > to write a PEP about that topic, incorporating the ideas/questions and > suggestions discussed here. There is now a PEP for the ordered dict: - PEP: http://www.python.org/dev/peps/pep-0372/ - Thread on comp.lang.python: http://thread.gmane.org/gmane.comp.python.general/577894 Regards, Armin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal: add odict to collections
Armin Ronacher wrote: Armin Ronacher active-4.com> writes: There are far more responses for that topic than I imagined so I would love to write a PEP about that topic, incorporating the ideas/questions and suggestions discussed here. There is now a PEP for the ordered dict: - PEP: http://www.python.org/dev/peps/pep-0372/ - Thread on comp.lang.python: http://thread.gmane.org/gmane.comp.python.general/577894 Another use case: in 2.6, RawConfigParser accepts a dict_type argument that allows an application to set the type of dictionary used internally. The motivation for this addition was expressly to allow users to provide an ordered dictionary [1]. Cheers, Nick. [1] http://bugs.python.org/issue1371075 -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Troubles with Roundup
Hello, I'm trying to login into the tracker but it gives me "invalid login" even after multiple password resets. I can't submit a proper bugreport because... I can't login :) Who can I privately contact to avoid spamming this list? Thanks! -- Giovanni Bajo Develer S.r.l. http://www.develer.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal: add odict to collections
[EMAIL PROTECTED] writes: > It is possible to get both ordered dict and sorted dict semantics in > the same type if you replace (key, value) pairs for dictionary entries > with (key,value,order) triples. Roundup uses something like this concept for its value choice menus. I don't actually think it's used, though, except as a way to allow admin user input that inserts an item at a position. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Troubles with Roundup
On Mon, Jun 16, 2008 at 9:18 AM, Giovanni Bajo <[EMAIL PROTECTED]> wrote: > Hello, > > I'm trying to login into the tracker but it gives me "invalid login" even > after multiple password resets. I can't submit a proper bugreport because... > I can't login :) > > Who can I privately contact to avoid spamming this list? > The tracker-discuss mailing list is the best place. Or file a bug on the meta-tracker. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Blow your mind
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A colleague just forward this to me and it blew my fscking mind to smithereens. It also brings back a lot of memories. Enjoy! - -Barry http://www.vimeo.com/1093745 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSFbK8XEjvBPtnXfVAQLPhwP/XQitqKSHHHUsYyrqN77G2FfIK0adyGNI /NUY0DGJQUKrL0Wy+LQQzXUqY0B9a2uk6hxyyA7qWYzd57/l7JCGCgWdEJPhOyxb Y8LW1N9z2SqdngaZHrQz1j5rRj5x2BFZpwt9/c/fqhbBhXIUrLnX/CZ342jQzneL WrKzvqemGlY= =JSCL -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Let me introduce myself! :)
Hi there! I'm Giovanni Simoni, known as Dacav. I'm a student of Computer Science at the University of Trento (Italy), a GNU/Linux user and, since I've tryied it for the first time, I've appreciated the expressive power of Python, so I'd like to delve into it. I subscribed this mailing list after reading the introduction to development (http://www.python.org/dev/intro/). I feel that it wolud be a good mean to improve my skillness with Python, even if I'm probably not enough experienced to bring a real contribute, for the moment. In the meanwhile I inform you that you have one more lurker! :) Thanks for your efforts, and regards Giovanni - -- Giovanni [Dacav] Simoni Linux User #414144 Molti pensano che l'apprendere a fare le cose, diventando uno scienziato, faccia sparire il mistero. Ciò che io sento è che il mistero motiva e nutre la scienza. La scoperta approfondisce il mistero. -- Manfred Eigen ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Blow your mind
On Mon, Jun 16, 2008 at 3:19 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > A colleague just forward this to me and it blew my fscking mind to > smithereens. It also brings back a lot of memories. Enjoy! Darn! I'm not on there yet. Anyway, it's nice to see Python development is exploding like fireworks now! -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] xmlrpclib.{True, False} (was Re: Assignment to None)
On 2008-06-15 16:47, Georg Brandl wrote:
Thomas Lee schrieb:
Georg Brandl wrote:
Remember that it must still be possible to write (in 2.6)
True = 0
assert not True
Ah of course. Looks like I should just avoid optimizations of
Name("True") and Name("False") all together. That's a shame!
We can of course decide to make assignment to True and False
illegal in 2.7 :)
Raising a run-time exception would be fine, but not a SyntaxError at
compile time - this would effectively make it impossible to keep
code compatible to Python 2.1.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jun 16 2008)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
2008-07-07: EuroPython 2008, Vilnius, Lithuania20 days to go
Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free !
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
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Blow your mind
On Mon, Jun 16, 2008 at 1:19 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > A colleague just forward this to me and it blew my fscking mind to > smithereens. It also brings back a lot of memories. Enjoy! > In case anyone cares to download the video, it's easy with Safari. Just go to the page and under Window -> Activity there is a list of all files downloaded for the page. Just double-click the multi-MB FLV file and Safari will download the Flash video file directly. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Epoch and Platform
The documentation for the time module says that "the epoch is the point where the time starts. On January 1st of that year, at 0 hours, the ``time since the epoch'' is zero. For Unix, the epoch is 1970. To find out what the epoch is, look at gmtime(0)." This confirms that the epoch is platform-specific. As such, the only legal uses of the timestamp should be 1) comparing with another timestamp to determine elapsed time in seconds 2) passing to another standard Python library function which expects a timestamp 3) as a source of randomness. However, the following files in the standard library have hardcoded the assumption that the Python epoch will always be the same as the Unix epoch: In gzip.py, method GzipFile._write_gzip_header In tarfile.py, method _Stream._init_write_gz In uuid.py, function uuid1 Additionally, the following files in the standard library have hardcoded the assumption that the Python epoch will cause timestamps to fall within the range of a 32-bit unsigned integer value: In imputil.py, function _compile In py_compile.py, function compile So there's some kind of a potential discrepancy here, albeit a minor one. This discrepancy can be resolved in one of at least three ways: 1) The documentation for the time module is wrong, and the epoch for Python (at least versions 2.x) should be the Unix epoch. 2) These library functions are slightly wrong and should be modified by subtracing an "epoch offset" before doing other calculations. This offset can be calculated as "time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 0)) - time.timezone". 3) These library files should be considered part of the platform-specific implementation, and an alternate platform should provide its own version of these files if necessary. Any thoughts on this? >From the perspective of implementing IronPython, I'd prefer that the answer is 1 or 2 -- but mainly I just want to be as compatible with "the spec" as possible, while respecting CLR-specific norms for functionality which is left up to individual implementations. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Epoch and Platform
ISTR that we force the epoch to be 1970 on all major platforms -- or perhaps it happens to be 1970 even on Windows when using MS's C runtime. On Mon, Jun 16, 2008 at 4:08 PM, Curt Hagenlocher <[EMAIL PROTECTED]> wrote: > The documentation for the time module says that "the epoch is the point > where the time starts. On January 1st of that year, at 0 hours, the ``time > since the epoch'' is zero. For Unix, the epoch is 1970. To find out what the > epoch is, look at gmtime(0)." This confirms that the epoch is > platform-specific. As such, the only legal uses of the timestamp should be > > 1) comparing with another timestamp to determine elapsed time in seconds > 2) passing to another standard Python library function which expects a > timestamp > 3) as a source of randomness. > > However, the following files in the standard library have hardcoded the > assumption that the Python epoch will always be the same as the Unix epoch: > In gzip.py, method GzipFile._write_gzip_header > In tarfile.py, method _Stream._init_write_gz > In uuid.py, function uuid1 > > Additionally, the following files in the standard library have hardcoded the > assumption that the Python epoch will cause timestamps to fall within the > range of a 32-bit unsigned integer value: > In imputil.py, function _compile > In py_compile.py, function compile > > So there's some kind of a potential discrepancy here, albeit a minor one. > This discrepancy can be resolved in one of at least three ways: > > 1) The documentation for the time module is wrong, and the epoch for Python > (at least versions 2.x) should be the Unix epoch. > 2) These library functions are slightly wrong and should be modified by > subtracing an "epoch offset" before doing other calculations. This offset > can be calculated as "time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 0)) - > time.timezone". > 3) These library files should be considered part of the platform-specific > implementation, and an alternate platform should provide its own version of > these files if necessary. > > Any thoughts on this? > > From the perspective of implementing IronPython, I'd prefer that the answer > is 1 or 2 -- but mainly I just want to be as compatible with "the spec" as > possible, while respecting CLR-specific norms for functionality which is > left up to individual implementations. > > -- > Curt Hagenlocher > [EMAIL PROTECTED] > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Epoch and Platform
>From what I remember, the Microsoft CLIB has been consistent with the Unix epoch since the bad old days of 16-bit. I believe that the Macintosh CLIB used to be based on January 1, 1904 -- but it's been a long time since I did any Mac development and I'm sure it would have changed with OS X. On Mon, Jun 16, 2008 at 4:38 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > ISTR that we force the epoch to be 1970 on all major platforms -- or > perhaps it happens to be 1970 even on Windows when using MS's C > runtime. > > On Mon, Jun 16, 2008 at 4:08 PM, Curt Hagenlocher <[EMAIL PROTECTED]> wrote: >> The documentation for the time module says that "the epoch is the point >> where the time starts. On January 1st of that year, at 0 hours, the ``time >> since the epoch'' is zero. For Unix, the epoch is 1970. To find out what the >> epoch is, look at gmtime(0)." This confirms that the epoch is >> platform-specific. As such, the only legal uses of the timestamp should be >> >> 1) comparing with another timestamp to determine elapsed time in seconds >> 2) passing to another standard Python library function which expects a >> timestamp >> 3) as a source of randomness. >> >> However, the following files in the standard library have hardcoded the >> assumption that the Python epoch will always be the same as the Unix epoch: >> In gzip.py, method GzipFile._write_gzip_header >> In tarfile.py, method _Stream._init_write_gz >> In uuid.py, function uuid1 >> >> Additionally, the following files in the standard library have hardcoded the >> assumption that the Python epoch will cause timestamps to fall within the >> range of a 32-bit unsigned integer value: >> In imputil.py, function _compile >> In py_compile.py, function compile >> >> So there's some kind of a potential discrepancy here, albeit a minor one. >> This discrepancy can be resolved in one of at least three ways: >> >> 1) The documentation for the time module is wrong, and the epoch for Python >> (at least versions 2.x) should be the Unix epoch. >> 2) These library functions are slightly wrong and should be modified by >> subtracing an "epoch offset" before doing other calculations. This offset >> can be calculated as "time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 0)) - >> time.timezone". >> 3) These library files should be considered part of the platform-specific >> implementation, and an alternate platform should provide its own version of >> these files if necessary. >> >> Any thoughts on this? >> >> From the perspective of implementing IronPython, I'd prefer that the answer >> is 1 or 2 -- but mainly I just want to be as compatible with "the spec" as >> possible, while respecting CLR-specific norms for functionality which is >> left up to individual implementations. >> >> -- >> Curt Hagenlocher >> [EMAIL PROTECTED] >> ___ >> Python-Dev mailing list >> [email protected] >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/guido%40python.org >> >> > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
