Re: [Python-Dev] Things to Know About Super

On 2008-08-27 09:54, Greg Ewing wrote: > Do you have a real-life example of this where multiple > inheritance is actually used? > > A non-contrived example or two would be a good thing to > have in tutorials etc. where super() is discussed. It > would help to convey the kinds of situations in whic

Re: [Python-Dev] Documentation Error for __hash__

On 2008-08-28 21:31, Michael Foord wrote: > Hello all, > > The documentation for __hash__ seems to be outdated. I'm happy to submit > a patch, so long as I am not misunderstanding something. > > http://docs.python.org/dev/reference/datamodel.html#object.__hash__ > > The documentation states: >

Re: [Python-Dev] Documentation Error for __hash__

On 2008-08-29 13:03, Matt Giuca wrote: >> Being hashable is a different from being usable as dictionary key. >> >> Dictionaries perform the lookup based on the hash value, but will >> then have to check for hash collisions based on an equal comparison. >> >> If an object does not define an equal co

[Python-Dev] 2.6b3 Windows installers

The download page doesn't list any Windows installer for 2.6b3: http://www.python.org/download/releases/2.6/ I suppose this is due to Martin building the installers and him not be available at the moment. Since Python on Windows will likely only get very few beta testers without a Windows instal

Re: [Python-Dev] Add python.exe to PATH environment variable

On 2008-09-02 23:14, Terry Reedy wrote: > Tarek Ziadé wrote: > >> So I don't see any good reason (besides the technical complexity) > > Unless and until someone is able and willing to deal with the technical > complexity, that would seem to be a sufficient reason. > >> to [not, I presume] add

Re: [Python-Dev] Add python.exe to PATH environment variable

On 2008-09-03 04:12, Greg Ewing wrote: > M.-A. Lemburg wrote: > >> The problem is: how to undo those changes without accidentally >> undoing an explicit change made by the user ? > > Is that really much of an issue? If the PATH contains an > entry corresponding to the

Re: [Python-Dev] Add python.exe to PATH environment variable

On 2008-09-03 10:15, Cesare Di Mauro wrote: > On 03 sep 2008 at 00:50:13, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > >> There already is a menu entry that starts the Python interpreter >> on Windows, so why not use that ? > > Because i need to start Python from f

Re: [Python-Dev] [Python-checkins] r66321 - in python/trunk: Doc/library/warnings.rst Lib/asynchat.py Lib/bsddb/test/test_early_close.py Lib/mimetools.py Lib/test/test___all__.py Lib/test/test_excepti

On 2008-09-09 02:49, brett.cannon wrote: > Author: brett.cannon > Date: Tue Sep 9 02:49:16 2008 > New Revision: 66321 > > Log: > warnings.catch_warnings() now returns a list or None instead of the custom > WarningsRecorder object. This makes the API simpler to use as no special > object > must b

Re: [Python-Dev] Filename as byte string in python 2.6 or 3.0?

On 2008-09-29 12:50, Ulrich Eckhardt wrote: > On Sunday 28 September 2008, Gregory P. Smith wrote: >> "broken" systems will always exist. Code to deal with them must be >> possible to write in python 3.0. >> >> since any given path (not just fs) can have its own encoding it makes >> the most sense

Re: [Python-Dev] [Python-3000] New proposition for Python3 bytes filename issue

On 2008-09-30 08:00, Martin v. Löwis wrote: >> Change the default file system encoding to store bytes in Unicode is like >> introducing a new Python type: . > > Exactly. Seems like the best solution to me, despite your polemics. Not a bad idea... have os.listdir() return Unicode subclasses that

Re: [Python-Dev] [Python-3000] New proposition for Python3 bytes filename issue

On 2008-09-30 16:05, Guido van Rossum wrote: > On Tue, Sep 30, 2008 at 3:31 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: >> On 2008-09-30 08:00, Martin v. Löwis wrote: >>>> Change the default file system encoding to store bytes in Unicode is like >>>> intro

Re: [Python-Dev] [Python-3000] New proposition for Python3 bytes filename issue

On 2008-09-30 18:46, Guido van Rossum wrote: > On Tue, Sep 30, 2008 at 8:20 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: >> In the end, I think it's better not to be clever and just return >> the filenames that cannot be decoded as bytes objects in os.listdir(). > &g

Re: [Python-Dev] [Python-3000] New proposition for Python3 bytes filename issue

On 2008-10-01 09:54, Ulrich Eckhardt wrote: > On Tuesday 30 September 2008, M.-A. Lemburg wrote: >> On 2008-09-30 08:00, Martin v. Löwis wrote: >>>> Change the default file system encoding to store bytes in Unicode is >>>> like introducing a new Python type: .

Re: [Python-Dev] Python3UnicodeDecodeError

On 2008-10-07 22:18, Fred Drake wrote: > On Oct 7, 2008, at 4:06 PM, Martin v. Löwis wrote: >> b) I would propose that the notion of a default encoding is entirely >> eliminated from Python, along with sys.(get|set)defaultencoding > > +1 As already mentioned in my reply to Viktor: +1. It's n

Re: [Python-Dev] [ANN] VPython 0.1

On 2008-10-22 14:16, J. Sievers wrote: > Hi, > > I implemented a variant of the CPython VM on top of Gforth's Vmgen; this made > it fairly straightforward to add direct threaded code and superinstructions > for > the various permutations of LOAD_CONST, LOAD_FAST, and most of the > two-argument >

Re: [Python-Dev] [ANN] VPython 0.1

On 2008-10-23 09:08, J. Sievers wrote: > a) It's fairly easy to implement different types of dispatch, simply by > changing a few macros (and while I haven't done this, it shouldn't be a > problem to add some switch dispatch #ifdefs for non-GCC platforms). > > In particular, direct threaded code l

Re: [Python-Dev] [ANN] VPython 0.1

On 2008-10-23 15:19, David Ripton wrote: > On 2008.10.23 12:02:12 +0200, M.-A. Lemburg wrote: >> BTW: I hope you did not use pybench to get profiles of the opcodes. >> That would most certainly result in good results for pybench, but >> less good ones for general applicati

Re: [Python-Dev] [ANN] VPython 0.1

On 2008-10-24 09:53, J. Sievers wrote: > "M.-A. Lemburg" <[EMAIL PROTECTED]> writes: > > [snip] >> BTW: I hope you did not use pybench to get profiles of the opcodes. >> That would most certainly result in good results for pybench, but >> less good ones

Re: [Python-Dev] Optionally using GMP to implement long if available

On 2008-11-04 18:38, Victor Stinner wrote: > Le Monday 03 November 2008 18:56:37 Paul Miller, vous avez écrit : >> Rather than that, what about patching Python's long implementation >> to use GMP if it's available, and the default implementation if not? > > Yes, I like this suggestion of two flav

Re: [Python-Dev] datetime and timedelta enhancement

On 2008-11-14 23:59, Victor Stinner wrote: > Hi, > > There are some interresting tickets about the datetime module: > #1673409: datetime module missing some important methods > #1083: Confusing error message when dividing timedelta using / > #2706: datetime: define division timedelta/timedelta > #

Re: [Python-Dev] datetime and timedelta enhancement

On 2008-11-16 02:14, Nick Coghlan wrote: > M.-A. Lemburg wrote: >> Guess I could add a .weeks attribute to mxDateTime, but no one ever >> asked for that so far. > > Given that there are at least 3 different ways to define the number of > "weeks" between two dates

Re: [Python-Dev] Python for windows.

On 2008-11-27 04:12, Bugbee, Larry wrote: > Not necessarily. I have no problems with hashlib or Python/M2Crypto/OpenSSL > as long as I'm doing memory-oriented operations. It is only when the > function does I/O that errors occur. ...like reading/writing a PEM file, > randpool.dat, etc. FWI

Re: [Python-Dev] Python for windows.

On 2008-11-28 00:15, Christian Heimes wrote: > Martin v. Löwis wrote: >>> All, and not to start flames, but I still do not understand why >>> applink.c isn't included in python's main (conditionally) instead of >>> expecting users, many of them novices, to do the build. ??? >> >> One reason is tha

Re: [Python-Dev] Python-3.0, unicode, and os.environ

On 2008-12-06 01:48, Nick Coghlan wrote: > You can't display a non-decodable filename to the user, hence the user > will have no idea what they're working on. Non-filesystem related apps > have no business trying to deal with insane filenames. This is not entirely true: OSes, shells, and applicati

Re: [Python-Dev] Python-3.0, unicode, and os.environ

On 2008-12-08 19:26, Guido van Rossum wrote: > On Sun, Dec 7, 2008 at 3:53 PM, Terry Reedy <[EMAIL PROTECTED]> wrote: >> Here is a possible use case: I want filenames as 3.0 strings and I >> anticipate no problems at present but, as you say above, something might >> happen years in the future. I a

Re: [Python-Dev] Python-3.0, unicode, and os.environ

On 2008-12-08 21:45, Antoine Pitrou wrote: > M.-A. Lemburg egenix.com> writes: >> Such application specific error handlers could then also apply >> whatever fancy round-trip safe encoding of non-decodable bytes >> to Unicode escapes, private code points, etc. as seen f

Re: [Python-Dev] Python-3.0, unicode, and os.environ

On 2008-12-08 22:32, Adam Olsen wrote: > On Mon, Dec 8, 2008 at 2:01 PM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: >> On 2008-12-08 21:45, Antoine Pitrou wrote: >>> M.-A. Lemburg egenix.com> writes: >>>> Such application specific error handlers could then al

Re: [Python-Dev] Python-3.0, unicode, and os.environ

On 2008-12-08 22:39, Victor Stinner wrote: >> ('strict', 'ignore', 'replace', 'xmlcharrefreplace') > > replace (or xmlcharrefreplace) is just useless because you will not be unable > to open or rename the file... You just know that there is a strange file in > the directory. Right, but that's a

Re: [Python-Dev] Python-3.0, unicode, and os.environ

On 2008-12-09 09:41, Anders J. Munch wrote: > On Sun, Dec 7, 2008 at 3:53 PM, Terry Reedy <[EMAIL PROTECTED]> wrote: try: files = os.listdir(somedir, errors = strict) except OSError as e: log() files = os.listdir(somedir) > > Instead of a codecs error handler name, how

Re: [Python-Dev] Trap SIGSEGV and SIGFPE

On 2008-12-10 21:05, Adam Olsen wrote: > On Wed, Dec 10, 2008 at 12:22 PM, BJörn Lindqvist <[EMAIL PROTECTED]> wrote: >> One thing i think it would be useful for in the real world is for >> unittesting extension modules. You cant profitably write unit tests >> for segfaults because that breaks the

Re: [Python-Dev] Trap SIGSEGV and SIGFPE

On 2008-12-11 19:15, Adam Olsen wrote: > On Thu, Dec 11, 2008 at 2:34 AM, Victor Stinner > wrote: >> Le Wednesday 10 December 2008 20:04:00 Terry Reedy, vous avez écrit : > Recover after a segfault is dangerous, but my first goal was to get the > Python backtrace instead just one line: "Se

Re: [Python-Dev] Reindenting the C code base?

On 2008-12-14 21:43, Martin v. Löwis wrote: >> Personally, I think the indentation of, at least, >> Objects/unicodeobject.c should be fixed. This file has become so >> mixed-up with tab and space indents that I have no-idea what to use >> when I edit it. Just to give an idea how messy it is, they a

Re: [Python-Dev] extremely slow exit for program having huge (45G) dict (python 2.5.2)

On 2008-12-20 17:57, Mike Coleman wrote: > On Sat, Dec 20, 2008 at 4:02 AM, Kristján Valur Jónsson > wrote: >> Can you distill the program into something reproducible? >> Maybe with something slightly less than 45Gb but still exhibiting some >> degradation of exit performance? >> I can try to poi

Re: [Python-Dev] extremely slow exit for program having huge (45G) dict (python 2.5.2)

On 2008-12-20 21:20, Leif Walsh wrote: > On Sat, Dec 20, 2008 at 3:04 PM, M.-A. Lemburg wrote: >> These long exit times are usually caused by the garbage collection >> of objects. This can be a very time consuming task. > > In that case, the question would be "why is

Re: [Python-Dev] extremely slow exit for program having huge (45G) dict (python 2.5.2)

On 2008-12-20 23:16, Martin v. Löwis wrote: >>> I will try next week to see if I can come up with a smaller, >>> submittable example. Thanks. >> These long exit times are usually caused by the garbage collection >> of objects. This can be a very time consuming task. > > I doubt that. The long exi

Re: [Python-Dev] extremely slow exit for program having huge (45G) dict (python 2.5.2)

On 2008-12-22 19:13, Mike Coleman wrote: > On Mon, Dec 22, 2008 at 6:20 AM, M.-A. Lemburg wrote: >> BTW: Rather than using a huge in-memory dict, I'd suggest to either >> use an on-disk dictionary such as the ones found in mxBeeBase or >> a database. > > I really

Re: [Python-Dev] extremely slow exit for program having huge (45G) dict (python 2.5.2)

On 2008-12-22 22:45, Steven D'Aprano wrote: > On Mon, 22 Dec 2008 11:20:59 pm M.-A. Lemburg wrote: >> On 2008-12-20 23:16, Martin v. Löwis wrote: >>>>> I will try next week to see if I can come up with a smaller, >>>>> submittable example. Thanks. >

Re: [Python-Dev] #ifdef __cplusplus?

On 2009-01-02 00:54, Nick Coghlan wrote: > Ulrich Eckhardt wrote: >> Hi! >> >> There are lots of files that are framed with an extern "C" stanza when >> compiled under C++. Now, I appreciate that header files are made suitable >> for >> use with C++ with that, but WTF are those doing in .c files

Re: [Python-Dev] #ifdef __cplusplus?

On 2009-01-02 08:26, Adam Olsen wrote: > On Thu, Jan 1, 2009 at 11:24 PM, Alexander Belopolsky > wrote: >> On Fri, Jan 2, 2009 at 12:58 AM, Adam Olsen wrote: >> .. >>> As C++ has more specific ways of allocating memory, they impose this >>> restriction to annoy you into using them. >> And so does

Re: [Python-Dev] #ifdef __cplusplus?

On 2009-01-03 04:15, Adam Olsen wrote: > On Fri, Jan 2, 2009 at 9:05 AM, M.-A. Lemburg wrote: >> On 2009-01-02 08:26, Adam Olsen wrote: >>> Python's malloc wrappers are pretty messy. Of your examples, only >>> unicode->str isn't obvious what the resu

Re: [Python-Dev] #ifdef __cplusplus?

On 2009-01-05 23:17, Mark Hammond wrote: > On 5/01/2009 11:13 PM, M.-A. Lemburg wrote: > >> See above. Assertions are not meant to be checked in a production >> build. You use debug builds for debugging such low-level things. > > Although ironically, assertions have been

Re: [Python-Dev] #ifdef __cplusplus?

trying to debug the MS CRT, only Python ;-) > Kristj'an > > -Original Message- > From: python-dev-bounces+kristjan=ccpgames@python.org > [mailto:python-dev-bounces+kristjan=ccpgames....@python.org] On Behalf Of > M.-A. Lemburg > Sent: 6. janúar 2009

Re: [Python-Dev] Decoder functions accept str in py3k

On 2009-01-07 16:34, Guido van Rossum wrote: > Sounds like yet another remnant of the old philosophy, which indeed > supported encode and decode operations on both string types. :-( No, that's something I explicitly readded to Python 3k, since the codecs interface is independent of the input and o

Re: [Python-Dev] Decoder functions accept str in py3k

On 2009-01-07 19:32, Antoine Pitrou wrote: > M.-A. Lemburg egenix.com> writes: >> No, that's something I explicitly readded to Python 3k, since the >> codecs interface is independent of the input and output types (the >> codecs decide which combinations to support)

Re: [Python-Dev] Fixing incorrect indentations in C files (Decoder functions accept str in py3k)

On 2009-01-08 01:01, Collin Winter wrote: > On Wed, Jan 7, 2009 at 2:35 PM, Brett Cannon wrote: >> On Wed, Jan 7, 2009 at 10:57, M.-A. Lemburg wrote: >> [SNIP] >>> BTW: The _codecsmodule.c file is a 4 spaces indent file as well (just >>> like all Unicode support

Re: [Python-Dev] Fixing incorrect indentations in C files (Decoder functions accept str in py3k)

y 4-space indents." > K > > -Original Message- > From: python-dev-bounces+kristjan=ccpgames@python.org > [mailto:python-dev-bounces+kristjan=ccpgames....@python.org] On Behalf Of > M.-A. Lemburg > Sent: 8. janúar 2009 09:49 > To: Collin Winter > Cc: Antoine

Re: [Python-Dev] Copyright notices in modules

On 2009-01-20 00:56, Raymond Hettinger wrote: > Why does numbers.py say: > ># Copyright 2007 Google, Inc. All Rights Reserved. ># Licensed to PSF under a Contributor Agreement. Because that's where that file originated, I guess. This is part of what you have to do for things that are lice

Re: [Python-Dev] Copyright notices in modules

On 2009-01-20 11:02, Michael Foord wrote: > M.-A. Lemburg wrote: >> [snip...] >> >>> Does the copyright concept even apply to an >>> abstract base class (I thought APIs were not >>> subject to copyright, just like database layouts >>> and lang

Re: [Python-Dev] Copyright notices in modules

On 2009-01-20 16:54, Stephen J. Turnbull wrote: > M.-A. Lemburg writes: > > On 2009-01-20 11:02, Michael Foord wrote: > > > > Mere collections of facts are not copyrightable as they are not > > > creative (the basis of copyright) > > That's incorrect

Re: [Python-Dev] Python 3.0.1

On 2009-01-27 22:19, Raymond Hettinger wrote: > From: ""Martin v. Löwis"" >> Releasing 3.1 6 months after 3.0 sounds reasonable; I don't think >> it should be released earlier (else 3.0 looks fairly ridiculous). > > I think it should be released earlier and completely supplant 3.0 > before more t

Re: [Python-Dev] Python 3.0.1

On 2009-01-29 01:59, Stephen J. Turnbull wrote: > I think there is definitely something to the notion that the 3.x > vs. 3.0.y distinction should signal something, and I personally like > MAL's suggestion that 3.0.x should be marked some sort of beta in > perpetuity, or at least until 3.1 is ready

Re: [Python-Dev] Python 3.0.1

On 2009-01-30 11:40, Antoine Pitrou wrote: > Aahz pythoncraft.com> writes: >> There's absolutely no reason not to have a 3.0.2 before 3.1 comes out. >> You're probably right that what Raymond wants to is best not done for >> 3.0.1 -- but once we've agreed in principle that 3.0.x isn't a true >> pr

Re: [Python-Dev] Strange locale problem with Python 3

On 2009-02-01 19:44, Reto Schüttel wrote: > Hi > > While helping Brandon Rhodes to port PyEphem[1] to Python 3 we struggled > over a > strange locale-related problem on OS X. PyEphem is a library which can do > astronomical computations like tracking the position of stars, planets and > earth sate

Re: [Python-Dev] PEP 393 Summer of Code Project

Stefan Behnel wrote: > Isaac Morland, 26.08.2011 04:28: >> On Thu, 25 Aug 2011, Guido van Rossum wrote: >>> I'm not sure what should happen with UTF-8 when it (in flagrant >>> violation of the standard, I presume) contains two separately-encoded >>> surrogates forming a valid surrogate pair; probab

Re: [Python-Dev] Should we move to replace re with regex?

Guido van Rossum wrote: > I just made a pass of all the Unicode-related bugs filed by Tom > Christiansen, and found that in several, the response was "this is > fixed in the regex module [by Matthew Barnett]". I started replying > that I thought that we should fix the bugs in the re module (i.e., >

Re: [Python-Dev] Should we move to replace re with regex?

Guido van Rossum wrote: > On Fri, Aug 26, 2011 at 3:09 PM, M.-A. Lemburg wrote: >> Guido van Rossum wrote: >>> I just made a pass of all the Unicode-related bugs filed by Tom >>> Christiansen, and found that in several, the response was "this is >>> fixe

Re: [Python-Dev] Ctypes and the stdlib (was Re: LZMA compression support in 3.3)

Guido van Rossum wrote: > On Sun, Aug 28, 2011 at 11:23 AM, Stefan Behnel wrote: >> Hi, >> >> sorry for hooking in here with my usual Cython bias and promotion. When the >> question comes up what a good FFI for Python should look like, it's an >> obvious reaction from my part to throw Cython into

Re: [Python-Dev] PEP 393 review

"Martin v. Löwis" wrote: > tl;dr: PEP-393 reduces the memory usage for strings of a very small > Django app from 7.4MB to 4.4MB, all other objects taking about 1.9MB. > > Am 26.08.2011 16:55, schrieb Guido van Rossum: >> It would be nice if someone wrote a test to roughly verify these >> numbers,

Re: [Python-Dev] Not able to do unregister a code

Jai Sharma wrote: > Hi, > > I am facing a memory leaking issue with codecs. I make my own ABC class and > register it with codes. > > import codecs > codecs.register(ABC) > > but I am not able to remove ABC from memory. Is there any alternative to do > that. The ABC codec search function gets a

Re: [Python-Dev] PEP 393 close to pronouncement

Guido van Rossum wrote: > Given the feedback so far, I am happy to pronounce PEP 393 as > accepted. Martin, congratulations! Go ahead and mark ity as Accepted. > (But please do fix up the small nits that Victor reported in his > earlier message.) I've been working on feedback for the last few days

Re: [Python-Dev] PEP 393 close to pronouncement

Victor Stinner wrote: >> Given that I've been working on and maintaining the Python Unicode >> implementation actively or by providing assistance for almost >> 12 years now, I've also thought about whether it's still worth >> the effort. > > Thanks for your huge work on Unicode, Marc-Andre! Thank

Re: [Python-Dev] Hash collision security issue (now public)

Mark Shannon wrote: > Michael Foord wrote: >> Hello all, >> >> A paper (well, presentation) has been published highlighting security >> problems with the hashing >> algorithm (exploiting collisions) in many programming languages Python >> included: >> >> >> http://events.ccc.de/congress/2011

Re: [Python-Dev] Counting collisions for the win

Frank Sievertsen wrote: > Hello, > > I'd still prefer to see a randomized hash()-function (at least for 3.3). > > But to protect against the attacks it would be sufficient to use > randomization for collision resolution in dicts (and sets). > > What if we use a second (randomized) hash-function

Re: [Python-Dev] PEP: New timestamp formats

Nick Coghlan wrote: > On Thu, Feb 2, 2012 at 10:16 PM, Victor Stinner Add an argument to change the result type - >>> >>> There should also be a description of the "set a boolean flag to >>> request high precision output" approach. >> >> You mean so

Re: [Python-Dev] accept string in a2b and base64?

Nick Coghlan wrote: > The reason Python 2's implicit str<->unicode conversions are so > problematic isn't just because they're implicit: it's because they > effectively assume *latin-1* as the encoding on the 8-bit str side. The implicit conversion in Python2 only works with ASCII content, pretty

Re: [Python-Dev] Add a frozendict builtin type

Victor Stinner wrote: >> See also the PEP 351. > > I read the PEP and the email explaining why it was rejected. > > Just to be clear: the PEP 351 tries to freeze an object, try to > convert a mutable or immutable object to an immutable object. Whereas > my frozendict proposition doesn't convert a

Re: [Python-Dev] Add a frozendict builtin type

Steven D'Aprano wrote: > M.-A. Lemburg wrote: >> Victor Stinner wrote: >>>> See also the PEP 351. >>> I read the PEP and the email explaining why it was rejected. >>> >>> Just to be clear: the PEP 351 tries to freeze an object, try to >

Re: [Python-Dev] Python install layout and the PATH on win32

Lindberg, Van wrote: > Mark, MAL, Martin, Tarek, > > Could you comment on this? > > This is in the context of changing the name of the 'Scripts' directory > on windows to 'bin'. Éric brings up the point (explained more below) > that if we make this change, packages made/installed the new pack

Re: [Python-Dev] Python install layout and the PATH on win32 (Rationale part 1: Regularizing the layout)

VanL wrote: > As this has been brought up a couple times in this subthread, I figured that > I would lay out the > rationale here. > > There are two proposals on the table: 1) Regularize the install layout, and > 2) move the python > binary to the binaries directory. This email will deal with

Re: [Python-Dev] Use QueryPerformanceCounter() for time.monotonic() and/or time.highres()?

Victor Stinner wrote: >>> You seem to have missed the episode where I explained that caching the last >>> value in order to avoid going backwards doesn't work -- at least not if the >>> cached value is internal to the API implementation. >>> >> Yes, and I can't find it by briefly searching my mail.

Re: [Python-Dev] [RFC] PEP 418: Add monotonic time, performance counter and process time functions

Victor Stinner wrote: > Hi, > > Here is a simplified version of the first draft of the PEP 418. The > full version can be read online. > http://www.python.org/dev/peps/pep-0418/ > > The implementation of the PEP can be found in this issue: > http://bugs.python.org/issue14428 > > I post a simplif

Re: [Python-Dev] TZ-aware local time

Just to add my 2 cents to this discussion as someone who's worked with mxDateTime for almost 15 years. I think we all agree that users of an application want to input date/time data using their local time (which may very well not be the timezone of the system running the application). On output th

Re: [Python-Dev] Split unicodeobject.c into subfiles?

Victor Stinner wrote: > Hi, > > I would like to split the huge unicodeobject.c file into smaller > files. It's just the longest C file of CPython: 14,849 lines. > > I don't know exactly how to split it, but first I would like to know > if you would agree with the idea. > > Example: > - Objects/

Re: [Python-Dev] Split unicodeobject.c into subfiles

On 23.10.2012 10:22, Benjamin Peterson wrote: > 2012/10/22 Victor Stinner : >> Hi, >> >> I forked CPython repository to work on my "split unicodeobject.c" project: >> http://hg.python.org/sandbox/split-unicodeobject.c >> >> The result is 10 files (included the existing unicodeobject.c): >> >> 117

Re: [Python-Dev] Split unicodeobject.c into subfiles

On 25.10.2012 08:42, Nick Coghlan wrote: >> Why are any of these codecs here in unicodeobjectland in the first >> place? Sure, they're needed so that Python can find its own stuff, >> but in principle *any* codec could be needed. Is it just an heuristic >> that the codecs needed for 99% of the wo

Re: [Python-Dev] Split unicodeobject.c into subfiles

On 25.10.2012 08:42, Nick Coghlan wrote: > unicodeobject.c is too big, and should be restructured to make any > natural modularity explicit, and provide an easier path for users that > want to understand how the unicode implementation works. You can also achieve that goal by structuring the code i

Re: [Python-Dev] Split unicodeobject.c into subfiles

On 25.10.2012 11:18, Maciej Fijalkowski wrote: > On Thu, Oct 25, 2012 at 8:57 AM, M.-A. Lemburg wrote: >> On 25.10.2012 08:42, Nick Coghlan wrote: >>>> Why are any of these codecs here in unicodeobjectland in the first >>>> place? Sure, they're needed

Re: [Python-Dev] Make extension module initialisation more like Python module initialisation

On 08.11.2012 13:47, Stefan Behnel wrote: > Hi, > > I suspect that this will be put into a proper PEP at some point, but I'd > like to bring this up for discussion first. This came out of issues 13429 > and 16392. > > http://bugs.python.org/issue13429 > > http://bugs.python.org/issue16392 > > S

Re: [Python-Dev] [Catalog-sig] accept the wheel PEPs 425, 426, 427

On 13.11.2012 10:51, "Martin v. Löwis" wrote: > Am 13.11.12 03:04, schrieb Nick Coghlan: >> On Mon, Oct 29, 2012 at 4:47 AM, Daniel Holth > > wrote: >> >> I think Metadata 1.3 is done. Who would like to czar? >> >> (Apologies for the belated reply, it's been a busy few

Re: [Python-Dev] [Python-checkins] Cron /home/docs/build-devguide

On 22.12.2012 21:36, Terry Reedy wrote: > > On 12/22/2012 1:30 PM, Cron Daemon wrote: >> abort: error: Connection timed out >> ___ >> Python-checkins mailing list >> python-check...@python.org >> http://mail.python.org/mailman/listinfo/python-checkins

Re: [Python-Dev] BDFL delegation for PEP 426 + distutils freeze

On 03.02.2013 19:33, Éric Araujo wrote: >> I vote for removing the "distutils is frozen" principle. > I’ve also been thinking about that. There have been two exceptions to > the freeze, for ABI flags in extension module names and for pycache > directories. When the stable ABI was added and MvL wa

Re: [Python-Dev] File encodings

Gustavo Niemeyer wrote: Greetings, Today, while trying to internationalize a program I'm working on, I found an interesting side-effect of how we're dealing with encoding of unicode strings while being written to files. Suppose the following example: # -*- encoding: iso-8859-1 -*- print u"á" Th

Re: [Python-Dev] File encodings

Gustavo Niemeyer wrote: [...] The idiom presented by Bob is the right way to go: wrap sys.stdout with a StreamWriter. I don't see that as a good solution, since every Python software that is internationalizaed will have do figure out this wrapping, introducing extra overhead unnecessarily. I don't

[Python-Dev] MS VC compiler versions

Preparing for the distutils patch to allow building extensions using the .NET SDK compilers, I am compiling a list of version numbers and MS compiler logo outputs in order to use these to identify the correct compiler to use for the extensions. These are the compilers I have found so far: * MS VC6

[Python-Dev] Removing --with-wctype-functions support

I would like to remove the support for using libc wctype functions (e.g. towupper(), towlower(), etc.) from the code base. The reason is that compiling Python using this switch not only breaks the test suite, it also causes the functions .lower() and .upper() to become locale aware and creates wron

Re: [Python-Dev] MS VC compiler versions

Here's an update of the list I currently have: * MS VS6 SP5 (International version, optimizing VC6 compiler with SP5): Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86 Copyright (C) Microsoft Corp 1984-1998. All rights reserved. * MS VC6 (German version; optimizing VC6 co

Re: [Python-Dev] Deprecated xmllib module

Martin v. Löwis wrote: As for PEP 4: I don't know whether it needs to be listed there. It appears that the PEP is largely unmaintained (I, personally, do not really maintain it). So one option would be to just stop using PEP 4 for recording deprecations, since we now have the warnings module. If we

Re: [Python-Dev] Rewriting PEP4

Barry Warsaw wrote: On Mon, 2004-12-06 at 16:28, "Martin v. Löwis" wrote: Martin, +1 on everything you wrote, with one minor quibble. Removal === If the module has been deprecated for atleast a year and atleast a version, it can be removed. Removal should move it to old-libs for pure Python mo

Re: [Python-Dev] csv module TODO list

Martin v. Löwis wrote: Andrew McNamara wrote: There's a bunch of jobs we (CSV module maintainers) have been putting off - attached is a list (in no particular order): * unicode support (this will probably uglify the code considerably). Can you please elaborate on that? What needs to be done, and h

Re: [Python-Dev] csv module TODO list

x27;s compiled twice using pre-processor macros). Quite a large job. Suggestions gratefully received. M.-A. Lemburg wrote: Indeed. The trick is to convert to Unicode early and to use Unicode literals instead of string literals in the code. Yes, although it would be nice to also retain the 8-bit versi

Re: [Python-Dev] csv module TODO list

Andrew McNamara wrote: Yes, although it would be nice to also retain the 8-bit versions as well. You can do so by using latin-1 as default encoding. Works great ! Yep, although that means we wear the cost of decoding and encoding for all 8 bit input. Right, but it makes the code very clean and stra

Re: [Python-Dev] Getting rid of unbound methods: patch available

Nick Coghlan wrote: Guido van Rossum wrote: What do people think? (My main motivation for this, as stated before, is that it adds complexity without much benefit.) I'm in favour, since it removes the "an unbound method is almost like a bare function, only not quite as useful" distinction. It woul

Re: [Python-Dev] Getting rid of unbound methods: patch available

Guido van Rossum wrote: Apart from the tests that were testing the behavior of im_class, I found only a single piece of code in the standard library that used im_class of an unbound method object (the clever test in the pyclbr test). Uses of im_self and im_func were more widespread. Given the level

Re: [Python-Dev] Getting rid of unbound methods: patch available

Guido van Rossum wrote: [Guido] Apart from the tests that were testing the behavior of im_class, I found only a single piece of code in the standard library that used im_class of an unbound method object (the clever test in the pyclbr test). Uses of im_self and im_func were more widespread. Given t

Re: [Python-Dev] __str__ vs. __unicode__

Walter Dörwald wrote: __str__ and __unicode__ seem to behave differently. A __str__ overwrite in a str subclass is used when calling str(), a __unicode__ overwrite in a unicode subclass is *not* used when calling unicode(): --- class str2(str): def __str__(self):

Re: [Python-Dev] Getting rid of unbound methods: patch available

Guido van Rossum wrote: [me] I'm not sure I understand how basemethod is supposed to work; I can't find docs for it using Google (only three hits for the query mxTools basemethod). How does it depend on im_class? [Marc-Andre] It uses im_class to find the class defining the (unbound) method: def ba

Re: [Python-Dev] __str__ vs. __unicode__

Walter Dörwald wrote: M.-A. Lemburg wrote: So the question is whether conversion of a Unicode sub-type to a true Unicode object should honor __unicode__ or not. The same question can be asked for many other types, e.g. floats (and __float__), integers (and __int__), etc. >>> class flo

Re: [Python-Dev] __str__ vs. __unicode__

Nick Coghlan wrote: M.-A. Lemburg wrote: So if we fix __str__ this would be a bugfix for 2.4.1. If we fix the rest, this would be a new feature for 2.5. I have a feeling that we're better off with the bug fix than the new feature. __str__ and __unicode__ as well as the other hooks

Re: [Python-Dev] __str__ vs. __unicode__

Walter Dörwald wrote: M.-A. Lemburg wrote: > [...] __str__ and __unicode__ as well as the other hooks were specifically added for the type constructors to use. However, these were added at a time where sub-classing of types was not possible, so it's time now to reconsider whet

Re: [Python-Dev] test_codecs failing

Walter Dörwald wrote: Raymond Hettinger wrote: The most recent test_codecs check-in (1.19) is failing on a MSCV6.0 compilation running on WinMe: -- Ran 35 tests in 1.430s FAILED (failures=1) Traceback (most recent call last): > [.

<    3   4   5   6   7   8   9   10   11   >