Re: [Python-Dev] To reduce Python "application" startup time

INADA Naoki wrote: > Current `python -v` is not useful to optimize import. > So I use this patch to profile import time. > https://gist.github.com/methane/e688bb31a23bcc437defcea4b815b1eb I have implemented DTrace probes that do almost the same thing. Your patch is better in that it does not requ

[Python-Dev] Re: my plans for subinterpreters (and a per-interpreter GIL)

On 2021-12-15 2:57 p.m., Guido van Rossum wrote: But as long as the imbalance is less than 0x_2000_, the refcount will remain in the inclusive range [ 0x_4000_ , 0x_7FFF_ ] and we can test for immortality by testing a single bit: if (o->ob_refcnt & 0x_4000_) Could we have a

[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11

On 2022-01-18 23:14, Gregory P. Smith wrote: Our stdlib unittest already enables warnings by default per https://bugs.python.org/issue10535. Getting the right people to pay attention to them is always the hard part. I wonder if we can do a bit better in that regard.  When I install 3rd party

[Python-Dev] Re: Move the pythoncapi_compat project under the GitHub Python or PSF organization?

On 2022-02-10 2:58 p.m., Victor Stinner wrote: Would it make sense to move the pythoncapi_compat project under the GitHub Python or PSF organization to make it more "official" and a little bit more sustainable? I think that makes sense.  Extensions typically have this kind of compatibility cod

[Python-Dev] Re: Move the pythoncapi_compat project under the GitHub Python or PSF organization?

On 2022-02-11 06:14, Petr Viktorin wrote: Sounds reasonable, but... The implication of endorsing code like this is that *we cannot change private API even in patch releases*, which I don't think is documented anywhere, and might be a bit controversial. I think we are still allowed to change

[Python-Dev] Re: Accepting PEP 675 - Arbitrary Literal String Type

On 2022-03-21, Gregory P. Smith wrote: > TL;DR - PEP 675 allows type checkers to help prevent bugs allowing > attacker-controlled data to be passed to APIs that declare themselves as > requiring literal, in-code strings. Great idea. I did something like this for HTML templating in the Quixote web

[Python-Dev] Re: What to do about invalid escape sequences

On 2019-08-10, Serhiy Storchaka wrote: > Actually we need to distinguish the the author and the user of the code and > show warnings only to the author. Using .pyc files was just an heuristic: > the author compiles the Python code, and the user uses compiled .pyc files. > Would be nice to have more

[Python-Dev] Re: Pass the Python thread state to internal C functions

On AMD64 Linux, the location of the thread local data seems to be stored in the GS CPU register[1]. It seems likely other platforms and other operating systems could do something similar. Passing threadstate as an explicit argument could be either faster or slower depending on how often you use i

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

Hi Victor, Thanks for putting work into this. I support the idea of slowly evolving the C API. It must be done carefully so as to not unnecessarily break 3rd party extensions. Changes must be made for well founded reasons and not just because we think it makes a "cleaner" API. I believe you ar

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

On 2020-06-23, Thomas Wouters wrote: > I think the ability for per-type allocation/deallocation routines isn't > really about efficiency, but more about giving more control to embedding > systems (or libraries wrapped by extension modules) about how *their* > objects are allocated. It doesn't make

[Python-Dev] Re: Deferred, coalescing, and other very recent reference counting optimization

On 2020-09-01, Larry Hastings wrote: > Personally I think the future of CPython is to change completely > over to tracing garbage collection.  It's so much friendlier to > multicore, which is clearly the future of programming.  I'd rather > see efforts in this area directed towards that goal. I th

[Python-Dev] Re: Deferred, coalescing, and other very recent reference counting optimization

On 2020-09-02, Greg Ewing wrote: > On 2/09/20 8:32 am, Neil Schemenauer wrote: > > The most obvious approach is to adopt a multi-threaded model like is > > done by modern Java. I.e. no GIL and non-thread safe core data > > structures. That sounds a bit scary but based

[Python-Dev] Re: Remove module's __version__ attributes in the stdlib

On 2020-10-14, Serhiy Storchaka wrote: > I propose to remove __version__ in all stdlib modules. Are there any > exceptions? I agree that these kinds of meta attributes are not useful and it would be nice to clean them up. However, IMHO, maybe the cleanup is not worth breaking Python programs. We

[Python-Dev] Re: Remove module's __version__ attributes in the stdlib

On 2020-10-15, Serhiy Storchaka wrote: > [..] it seems that there are no usages the __version__ variable in > top 4K pypi packages. Given that, I think it's fine to remove them. If we find broken code during the alpha release we still have a chance to revert. However, it would seem quite unlikely

Re: [Python-Dev] Silencing IO errors on del/dealloc?

Guido van Rossum wrote: > No. Trust me. It is not always possible to strengthen the > implementation. (At least not until we get rid of the "replace all > globals with None upon module deletion" rule.) We should do that. Trying to do cleanup without globals sucks. I updated Armin's patch that's

Re: [Python-Dev] Silencing IO errors on del/dealloc?

Guido van Rossum wrote: > So how do you get destructors to run in that case? Or do you just not > run them? Then open files may not be closed and may not even see their > buffer flushed. I'm not happy about that. Unfortantely I don't have an up-to-date understand of the issues regarding modules a

[Python-Dev] Instructions on using git mirror

I've revised my instructions on using the experimental git mirror of the Python SVN repository: http://python.ca/nas/tmp/git-notes.txt Stories of success or failure welcome. Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.or

Re: [Python-Dev] Instructions on using git mirror

On Fri, Feb 27, 2009 at 08:36:08AM -0600, Brad Miller wrote: > when I get to the step git svn fetch I get the following error: > zsh-% git svn fetch > Permission denied (publickey). > Network connection closed unexpectedly: Connection closed unexpectedly at > /opt/local/bin/git-svn line 1385 > >

Re: [Python-Dev] Instructions on using git mirror

David Ripton wrote: > I don't see any point to using Neil's complicated dual-remote git + > git-svn setup if you don't have commit access. Good point. I will write another, hopefully simpler, set of instructions for read-only access. Neil ___ Pytho

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

Chris McDonough wrote: > As far as I can tell, asyncore/asynchat is all "undocumented > internals". Any use of asyncore in anger will use internals; > there never was any well-understood API to these modules. What I would like to see is a module that provides a low-level API for doing cross-plat

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

gl...@divmod.com wrote: > ... which is exactly why I have volunteered to explain to someone how to > separate the core event-loop bits (suitable for inclusion in the > standard library) from the huge pile of protocol implementations which > are not necessarily useful. > > Despite the FUD to the

Re: [Python-Dev] Issues with Py3.1's new ipaddr

Barry Warsaw wrote: > It would be really nice if say the Cheeseshop had a voting feature. > Use PEP 10 voting to get a rough estimate of a module's popularity > (download counts alone might not tell you everything). Then at least > you can get a rough idea of how generally popular a module

[Python-Dev] Better module shutdown procedure

The current shutdown code in pythonrun.c zaps module globals by setting them to None (an attempt to break reference cycles). That causes problems since __del__ methods can try to use the globals after they have been set to None. The procedure implemented by http://bugs.python.org/issue812369 seems

Re: [Python-Dev] Better module shutdown procedure

On Wed, Oct 14, 2009 at 04:13:12PM -0500, Daniel Stutzbach wrote: > Based on the description, it still resorts to zapping module globals by > setting them to None. It zaps them to weakrefs first, which means that > globals are more likely to be valid during __del__, but it still cannot make > any

Re: [Python-Dev] Better module shutdown procedure

On Wed, Oct 14, 2009 at 08:35:28PM -, exar...@twistedmatrix.com wrote: > I notice that the patch doesn't include any unit tests for the feature > being provided That's hard to do although I suppose not impossible. We would be trying to test the interpreter shutdown procedure. I suppose on pl

Re: [Python-Dev] Better module shutdown procedure

On Wed, Oct 14, 2009 at 05:35:38PM -0500, Daniel Stutzbach wrote: > The first and last sentences seem like a contradiction to me. If I cannot > guarantee that globals will be valid when __del__ is executed, then I must > not reference globals from __del__. I think there is confusion about the wor

Re: [Python-Dev] Better module shutdown procedure

Antoine Pitrou wrote: > Have you tried to remove the various hacks/workarounds in the > stdlib that currently avoid module finalization problems? Good idea. These hacks are the best argument for applying the change, IMHO. I made a quick review of Lib modules using __del__: tarfile: looks not

Re: [Python-Dev] Better module shutdown procedure

On Wed, Oct 14, 2009 at 02:16:35PM -0600, Neil Schemenauer wrote: > The procedure implemented by http://bugs.python.org/issue812369 > seems to be a better idea. After some experimentation I realize this idea is not ready yet. The main problem comes from references to Python objects that m

Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2

Benjamin Peterson wrote: > On behalf of the Python development team, I'm gleeful to announce > the second alpha release of Python 2.7. Thanks to everyone who contributed. > Python 2.7 is scheduled to be the last major version in the 2.x > series. Has this really been decided already? Maybe I mi

Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2

On Sun, Jan 10, 2010 at 12:09:08PM -0800, Brett Cannon wrote: > I don't think ending the 2.x series at 2.7 makes it look bad > compared to 3.2; it's simply the end of a development line like > any other software project. I suspect 2.7 will have a protracted > bugfix window because so much code runs

Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2

On Sun, Jan 10, 2010 at 07:46:04PM -0800, Brett Cannon wrote: > On Sun, Jan 10, 2010 at 17:44, Neil Schemenauer wrote: > > After the Python 2.7 release, the focus of Python development > > will be on Python 3. There will continue to be maintainance > > releases o

Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2

On Mon, Jan 11, 2010 at 12:02:01AM +0100, "Martin v. Löwis" wrote: > [...] would it still be ok if I closed a 2.x feature request as > "won't fix", or only committed the new feature to the 3.x branch? Yes. Non-bugfix development on 2.x would optional (i.e. done by people who want to spend the tim

Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2

On Sun, Jan 10, 2010 at 09:06:15PM -0800, Brett Cannon wrote: > If people start taking the carrots we have added to 3.x and > backporting them to keep the 2.x series alive you are essentially > making the 3.x DOA by negating its benefits which I personally > don't agree with. I think we have got t

Re: [Python-Dev] PEP 3147: PYC Repository Directories

Nick Coghlan wrote: > Henning von Bargen wrote: >> The solution is so obvious: >> >> Why not use a .pyr file that is internally a zip file? I think a Zip file might be the right approach too. Either you could have directories in the zip file for each version, e.g. 2.7/foo.pyc 3.3/foo.p

[Python-Dev] Rational for PEP 3147 (PYC Respository Directories)

Hi Barry, Thanks for doing the work of writing a PEP. The rational section could use some strengthing, I think. Who is benefiting from this feature? Is it the distribution package maintainers? Maybe people who use a distribution packaged Python and install packages from PyPI. It's not clear t

[Python-Dev] Using git to checkout Python

For those interested, I updated my instructions for using the git repositories on svn.python.org. They are now on the Python wiki: http://wiki.python.org/moin/Git Regards, Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python

Re: [Python-Dev] module shutdown procedure

Georg Brandl wrote: > Am 22.07.2010 13:29, schrieb Antoine Pitrou: >> Is it the reason why? With the new module creation API in 3.x, extension >> modules should be able to handle deletion of their own internal >> resources. > > Yes, but as Martin noted at the summit, nobody since went through all

Re: [Python-Dev] Looking after the buildbots (in general)

Georg Brandl wrote: > The hard part is to know *when* to look. As you might have noticed, the > Python test suite does not run in ten seconds, especially on some of the > buildbots -- it can take 1-2 there to complete. Based on this and other issues, I don't think it's practical to expect that p

Re: [Python-Dev] Issue 10194 - Adding a gc.remap() function

Peter Ingebretson wrote: > I am happy to write up a PEP for this feature. I'll start that > process now, though if anyone feels that this idea has no chance of > acceptance please let me know. I think a feature that allows modules to be more reliability reloaded could be accepted. Martin's su

Re: [Python-Dev] Continuing 2.x

I have a specific, easy to implement proposal. I would like one more version tag added to the Roundup tracker. My proposed name is "Python 2.7+" but I don't care what it is called. It would be used to tag bug reports and patches that apply only to the 2.x line and are considered not appropriate

[Python-Dev] Unary minus bug

The bug was reported by Armin in SF #1333982: the literal -2147483648 (i.e. the value of -sys.maxint-1) gives a long in 2.5, but an int in <= 2.4. I have a fix but I wonder if it's the right thing to do. I suppose returning a long has the chance of breaking someone code. Here's the test

Re: [Python-Dev] Unary minus bug

On Sun, Jul 09, 2006 at 03:02:06PM -0700, Neal Norwitz wrote: > Do we care about this (after your checkin and with my fix to make > 32-63 bit values ints rather than longs): > > # 64 bit box > >>>minint = str(-sys.maxint - 1) > >>>minint > '-9223372036854775808' > >>>eval(minint) > -92233720368547

Re: [Python-Dev] no remaining issues blocking 2.5 release

Neal Norwitz <[EMAIL PROTECTED]> wrote: > I don't know of any. I haven't heard of any issues with the fixes > that have been checked in. It would be nice if someone could bytecompile Lib using Tools/compiler/compile.py and then run the test suite. I'd do it myself but can't spare the time at the

Re: [Python-Dev] no remaining issues blocking 2.5 release

Neal Norwitz <[EMAIL PROTECTED]> wrote: > On 8/15/06, Neil Schemenauer <[EMAIL PROTECTED]> wrote: >> >> It would be nice if someone could bytecompile Lib using >> Tools/compiler/compile.py and then run the test suite. > > Has this been done before? Obviousl

Re: [Python-Dev] String formatting / unicode 2.5 bug?

John J Lee <[EMAIL PROTECTED]> wrote: > The note (4) says that the result will be unicode, but it doesn't say how, > in this case, that comes about. This case is confusing because the docs > claim string formatting with %s "converts ... using str()", and yet > str(a()) returns a bytestring. Do

Re: [Python-Dev] New syntax for 'dynamic' attribute access

M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > You can add a -1 from me to the list as well: I don't think that > dynamic lookups are common enough to warrant new syntax. I agree. Also, I think the special syntax may make them too inviting to new programmers, who haven't figured out that usually ther

Re: [Python-Dev] Python-3000 upgrade path

Neal Norwitz <[EMAIL PROTECTED]> wrote: > The time schedules in PEP 361 (2.6 release schedule) and what Guido > has said for 3k (from what I remember) are roughly: > > April 2007 - 3.0 PEPs and features accepted/decided > June 2007 - 3.0a1 - basic (most) features implemented Any talk at PyCon r

Re: [Python-Dev] Python-3000 upgrade path

On Sun, Feb 25, 2007 at 05:37:08PM -0600, Guido van Rossum wrote: > Right. To be honest, I consider the str/unicode unification a much > bigger project than the new I/O library. I was more concerned about IO because it would seem to require your time for design work. The str/unicode work could be

Re: [Python-Dev] Encouraging developers

A.M. Kuchling <[EMAIL PROTECTED]> wrote: > At PyCon, there was general agreement that exposing a read-only > Bazaar/Mercurial/git/whatever version of the repository wouldn't be > too much effort, and might make things easier for external people > developing patches. Thomas Wouters apparently has p

Re: [Python-Dev] Encouraging developers

Neil Schemenauer <[EMAIL PROTECTED]> wrote: > Using git-svn to track a SVN repository seems to work well. It > would be trivial to setup a cron job on one of the python.org > machines that would create a publicly accessible repository. I guess Andrew was looking for specif

Re: [Python-Dev] Encouraging developers

On Tue, Mar 06, 2007 at 10:26:50AM +0100, Thomas Wouters wrote: > I'm not interested in setting up GIT myself, mostly because it > doesn't solve any issues that other dvcs' don't solve dvcs wars are the new editor wars. :-) > the on-disk repository is mighty big and it doesn't work very well > on

Re: [Python-Dev] Possible optimization for LOAD_FAST ?

Barry Warsaw wrote: > On Jan 04, 2011, at 10:21 AM, Alex Gaynor wrote: > >>Ugh, I can't be the only one who finds these special cases to be a little >>nasty? >> >>Special cases aren't special enough to break the rules. > > Yeah, I agree. Still it would be interesting to see what kind of > perform

Re: [Python-Dev] About raising NotPortableWarning for CPython specific code

Greg Ewing wrote: > So am I. It seems to result from the hisorical mess > of distinguishing between numeric and sequence operations > at the C level but not the Python level. I think CPython > should be moving in the direction of eliminating that > distinction, not expecting all other Python imple

Re: [Python-Dev] Hg: inter-branch workflow

Guido van Rossum wrote: > What is "rebase"? Why does everyone want it and hate it at the same time? It's the same thing that happens when you do a "svn up" with local changes in your checkout. Logically, your patch gets modified so that it applies on a different (newer) version of the code. If

Re: [Python-Dev] Hg: inter-branch workflow

Barry Warsaw wrote: > I'm asking because I don't know hg and git well enough to answer the > question. In my own use of Bazaar over the last 4+ years, I've almost never > rebased or even been asked to. Maybe it depends on what kind of changes you commit. I consider future maintainers the most i

Re: [Python-Dev] Policy for making changes to the AST

As a user of the AST, I as well favor just changing the AST and the version. IMHO, it is not intended to be stable between Python releases (similar to bytecode). Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/li

Re: [Python-Dev] hard linking executables

Guido van Rossum wrote: > I ought to remember why because I remember I was involved. (And I have > a feeling that the change Antoine dug up was just a refactoring, You are correct. I checked Python 1.5.2 and it also creates hard links (prior to Makefile overhaul). > The best I can come up with

Re: [Python-Dev] GC Changes

Martin v. Löwis <[EMAIL PROTECTED]> wrote: >> Why isn't the mark-and-sweep mechanism used for all memory >> management? > > See above - it's not implementable, because the root objects get not > tracked. To further elaborate, the main obstacle is with extension modules. Most of them create roots a

Re: [Python-Dev] What to do for bytes in 2.6?

Guido van Rossum <[EMAIL PROTECTED]> wrote: > This may seem trivial (because we do all the work, and 2to3 just > leaves stuff alone), but having b"" and bytes as aliases for "" and > str in 2.6 would mean that we could write 2.6 code that correctly > expresses the use of binary data -- and we could

Re: [Python-Dev] What to do for bytes in 2.6?

Guido van Rossum <[EMAIL PROTECTED]> wrote: > bytes is an alias for str (not even a subclass) > b"" is an alias for "" One advantage of a subclass is that there could be a flag that warns about combining bytes and unicode data. For example, b"x" + u"y" would produce a warning. As someone who wri

Re: [Python-Dev] int/float freelists vs pymalloc

Christian Heimes <[EMAIL PROTECTED]> wrote: > +1 on focusing on improving pymalloc to handle int and float >object allocations even better I wonder if the int and float types could use a faster internal pymalloc interface. I can't remember the details but I seem to recall that pymalloc must j

Re: [Python-Dev] Py_CLEAR to avoid crashes

Nick Coghlan <[EMAIL PROTECTED]> wrote: > The problem is calls to Py_DECREF(self->attr) where some of the code > invoked by __del__ manages to find a way back around to reference > self->attr and gets access to a half-deleted object. Don't you mean "__del__ manages to find a way back around to s

Re: [Python-Dev] Py_CLEAR to avoid crashes

On Mon, Feb 18, 2008 at 05:48:57PM +0100, Amaury Forgeot d'Arc wrote: > For example, in exception.c, BaseException_init() starts with the instruction: > Py_DECREF(self->args); > this may call __del__ on self->args Ah, I understand now. We are not talking about tp_dealloc methods (the GC takes

Re: [Python-Dev] Py_CLEAR to avoid crashes

I wrote: > Most Py_DECREF calls are probably okay but it's going to be hard > to find the ones that are not. I suppose Py_DECREF is not the only source of trouble. Many calls to the Python API can end up calling arbitrary user code (via __getattr__, __getitem__, etc.). Whenever an object does th

Re: [Python-Dev] Proposal: Run GC less often

Greg Ewing <[EMAIL PROTECTED]> wrote: > Martin v. Löwis wrote: > >> Under my proposal, 10 middle collections must have passed, >> PLUS the number of survivor objects from the middle generation >> must exceed 10% of the number of objects in the oldest >> generation. > > What happens if the program e

[Python-Dev] git repositories for trunk and py3k

Hi, In case anyone is interested, I have git repositories for both the trunk and the py3k branch of the Python source code. They are up-to-date and so using them with git-svn would be much faster than starting from scratch. If anyone is interested, I will find a place to host them. They are eac

Re: [Python-Dev] git repositories for trunk and py3k

On Mon, Jul 14, 2008 at 09:31:47PM -0400, Barry Warsaw wrote: > Neil, we should try to host them on code.python.org. I was hoping to get a sense of the interest. Oh well, if you build it they might come. ;-) I've written draft instructions, temporarily at .

Re: [Python-Dev] git repositories for trunk and py3k

Benjamin Peterson <[EMAIL PROTECTED]> wrote: > Can we push branches? The git-daemon is setup as read-only. If you have write access to the SVN repository then you can push back changes using git-svn. That's quite a nice way to work, IMHO and provides an easy path for people who are used to Subver

Re: [Python-Dev] git repositories for trunk and py3k

[back on the list] On Thu, Jul 17, 2008 at 11:24:16PM -0700, Brett Cannon wrote: > Turned out to be a rebuild:: > > > r65077 = 82d954e8c20c91562c4c660859d17756cba10992 > r65082 = 1c75cce93c2ef2ec87e801888638cfdf5d2ff29a > r65085 = 3143c2fbe7315afd29496dc0cdac3122bed30536 > Done rebuilding .g

Re: [Python-Dev] git repositories for trunk and py3k

On Fri, Jul 18, 2008 at 11:12:41AM -0700, Brett Cannon wrote: > >git log git-svn.. > > And those two periods are significant for people who think they are > line noise. Damn is Git quirky. I guess it would have been clearer if I had used "git-svn..HEAD". The ".." is similar to SVN's ":" so I

Re: [Python-Dev] git repositories for trunk and py3k

On Fri, Jul 18, 2008 at 11:57:21AM -0700, Brett Cannon wrote: > I figured this out. I just did ``git reset --hard``, did the proper > "fetch;rebase" dance, resolved the conflict, did ``git add`` and then > continued with the rebase. It all looks fine now. Doing a fetch followed by a rebase is simi

Re: [Python-Dev] git repositories for trunk and py3k

On Fri, Jul 18, 2008 at 12:07:19PM -0700, Brett Cannon wrote: > I lied. Trying again complained about Mac/IDLE/Makefile.in which I > have not touched, nor is it listed as changed. I think you are running into the fact that the git tree on code.python.org is only updated every 30 minutes. Using th

Re: [Python-Dev] Fwd: Removal of GIL through refcounting removal.

Sigurd Torkel Meldgaard <[EMAIL PROTECTED]> wrote: > For a student project in a course on virtual machines, we are > evaluating the possibility to experiment with removing the GIL > from CPython Hi, It's great to hear of this kind of project. I think what you want to do is difficult but possible

Re: [Python-Dev] PEP 394 request for pronouncement (python2 symlink in *nix systems)

Guido van Rossum wrote: > Does this need a pronouncement? Worrying about the speed of symlinks > seems silly I agree. I wonder if a hard-link was used for legacy reasons. Some very old versions of Unix didn't have symlinks. It looks like it was introduced in BSD 4.2, released in 1983. That se

Re: [Python-Dev] Issue #10278 -- why not just an attribute?

Jim J. Jewett wrote: > Passing strict as an argument seems like overkill since it will always > be meaningless on some (most?) platforms. A keyword argument that gets passed as a constant in the caller is usually poor API. Why not have two different functions? Neil __

Re: [Python-Dev] 2.4 news reaches interesting places

On Wed, Dec 08, 2004 at 02:18:48PM -0800, Guido van Rossum wrote: > This is a PR issue that Python needs to fight -- any ideas? I'm not good at PR so I will continue to try to make it faster. In my copious free time I plan to: * finish the AST compiler (no performance benefit but makes

Re: [Python-Dev] Decimal & returning NotImplemented (or not)

On Tue, Mar 01, 2005 at 11:45:43PM +1000, Nick Coghlan wrote: > Interesting. In that case, my other suggestion was to have raising > NotImplementedError from a special method be the equivalent of returning > NotImplemented (which makes life much easier for a class like Decimal which > has an int

Re: [Python-Dev] unicode inconsistency?

On Sat, Apr 04, 1998 at 07:04:02AM +, Tim Peters wrote: > [Martin v. L?wis] > > I can't see any harm by supporting this operation also if __str__ returns > > a Unicode object. > > It doesn't sound like a good idea to me, at least in part because it > would be darned messy to implement short of

Re: [Python-Dev] unicode inconsistency?

On Wed, Mar 09, 2005 at 11:10:59AM +0100, M.-A. Lemburg wrote: > The patch implements the PyObjbect_Text() idea (an API that > returns a basestring instance, ie. string or unicode) and > then uses this in '%s' (the string version) to properly propogate > to u'%s' (the unicode version). > > Maybe w

Re: [Python-Dev] [AST] question about marshal_write_*() fxns

On Mon, Mar 21, 2005 at 11:53:04AM -0500, Brett C. wrote: > But one of things I am not sure of is what the marshal_write_*() functions > in Python/Python-ast.c are used for. I assume they output to the marshal > format, but there is mention of a byte stream format and so I thought it > might be

Re: [Python-Dev] Unified or context diffs?

On Wed, Apr 13, 2005 at 12:54:08PM -0700, Brett C. wrote: > I thought at one point this question came up and the general > consensus was that unified diffs were preferred? Guido used to prefer context diffs but says he now doesn't mind unified diffs. I think unified diffs are much more common the

Re: [Python-Dev] Re: anonymous blocks

On Wed, Apr 27, 2005 at 12:30:22AM -0700, Guido van Rossum wrote: > I've written a PEP about this topic. It's PEP 340: Anonymous Block > Statements (http://python.org/peps/pep-0340.html). [Note: most of these comments are based on version 1.2 of the PEP] It seems like what you are proposing is a

Re: [Python-Dev] Re: anonymous blocks

On Wed, Apr 27, 2005 at 03:58:14PM -0700, Guido van Rossum wrote: > Time to update the PEP; I'm pretty much settled on these semantics > now... [I'm trying to do a bit of Guido channeling here. I fear I may not be entirely successful.] The the __error__ method seems to simplify things a lot. Th

Re: [Python-Dev] noob question regarding the interpreter

On Thu, Apr 28, 2005 at 05:47:18PM -0400, Jing Su wrote: > Is there work to change python into a direct-threaded or even JIT'ed > interpreter? People have experimented with making the ceval loop use direct threading. If I recall correctly, the resulting speedup was not significant. I suspect th

Re: [Python-Dev] PEP 340 - possible new name for block-statement

On Thu, Apr 28, 2005 at 03:55:03PM -0700, Guido van Rossum wrote: > A variation on this with somewhat different semantics swaps the keywords: > > in EXPR for VAR: > BLOCK Looks weird to my eyes. On a related note, I was thinking about the extra cleanup 'block' provides. If the 'file

Re: [Python-Dev] gcmodule issue w/adding __del__ to generator objects

On Sat, Jun 18, 2005 at 06:24:48PM -0400, Phillip J. Eby wrote: > So, I think I've got this sorted out, assuming that I'm not doing > something hideously insane by having 'has_finalizer()' always > check tp_del even for non-heap types, and defining a tp_del slot > for generators to call close() in.

Re: [Python-Dev] PEP 332 revival in coordination with pep 349? [ Was:Re: release plan for 2.5 ?]

Guido van Rossum <[EMAIL PROTECTED]> wrote: >> In py3k, when the str object is eliminated, then what do you have? >> Perhaps >> - bytes("\x80"), you get an error, encoding is required. There is no >> such thing as "default encoding" anymore, as there's no str object. >> - bytes("\x80", encoding="la

Re: [Python-Dev] PEP 332 revival in coordination with pep 349? [ Was:Re: release plan for 2.5 ?]

On Mon, Feb 13, 2006 at 08:07:49PM -0800, Guido van Rossum wrote: > On 2/13/06, Neil Schemenauer <[EMAIL PROTECTED]> wrote: > > "\x80".encode('latin-1') > > But in 2.5 we can't change that to return a bytes object without > creating HUG

Re: [Python-Dev] byte literals unnecessary [Was: PEP 332 revival in coordination with pep 349?]

On Tue, Feb 14, 2006 at 03:13:37PM -0800, Guido van Rossum wrote: > Also, bytes objects are (in my mind anyway) mutable. We have no other > literal notation for mutable objects. What would the following code > print? > > for i in range(2): > b = b"abc" > print b > b[0] = ord("A") >

Re: [Python-Dev] bytes type needs a new champion

Guido van Rossum <[EMAIL PROTECTED]> wrote: > Anyway, we need a new PEP author who can take the current > discussion and turn it into a coherent PEP. I'm not sure that I have time to be the official champion. Right now I'm spending some time to collect all the ideas presented in the email message

[Python-Dev] from __future__ import unicode_strings?

I'm in the process of summarizing the dicussion on the bytes object and an idea just occured to me. Imagine that I want to write code that deals with strings and I want to be maximally compatible with P3k. It would be nice if I could add: from __future__ import unicode_strings and have stri

Re: [Python-Dev] from __future__ import unicode_strings?

On Thu, Feb 16, 2006 at 02:43:02AM +0100, Thomas Wouters wrote: > On Wed, Feb 15, 2006 at 05:23:56PM -0800, Guido van Rossum wrote: > > > > from __future__ import unicode_strings > > > Didn't we have a command-line option to do this? I believe it was > > removed because nobody could see the p

[Python-Dev] Pre-PEP: The "bytes" object

Title: The "bytes" object Version: $Revision$ Last-Modified: $Date$ Author: Neil Schemenauer <[EMAIL PROTECTED]> Status: Draft Type: Standards Track Content-Type: text/plain Created: 15-Feb-2006 Python-Version: 2.5 Post-History: Abstract This PEP outlines the introd

Re: [Python-Dev] Pre-PEP: The "bytes" object

On Thu, Feb 16, 2006 at 12:47:22PM -0800, Guido van Rossum wrote: > BTW, for folks who want to experiment, it's quite simple to create a > working bytes implementation by inheriting from array.array. Here's a > quick draft (which only takes str instance arguments): Here's a more complete prototype

Re: [Python-Dev] Pre-PEP: The "bytes" object

Michael Hoffman <[EMAIL PROTECTED]> wrote: > Am I the only one who finds the use of "self" on a classmethod to be > incredibly confusing? Can we please follow PEP 8 and use "cls" > instead? Sorry, using "self" was an oversight. It should be "cls", IMO. Neil ___

Re: [Python-Dev] Pre-PEP: The "bytes" object

Ron Adam <[EMAIL PROTECTED]> wrote: > Why was it decided that the unicode encoding argument should be ignored > if the first argument is a string? Wouldn't an exception be better > rather than give the impression it does something when it doesn't? >From the PEP: There is no sane meaning th

Re: [Python-Dev] .len() instead of __len__() (was: iterator API in Py3.0)

Oleg Broytmann <[EMAIL PROTECTED]> wrote: > What are disadvantages of a direct .len() instead of .__len__()? I can think of a few arguments against getting rid of double underscores in general. First, special methods are a little like keywords in that it would be nice to introduce new ones from t

Re: [Python-Dev] Slightly OT: Replying to posts

Talin <[EMAIL PROTECTED]> wrote: > However, I would like to be able to reply to posts in such a way as to > have them appear in the appropriate place in the thread hierarchy. The message should have a References header that contains the Message-Id of the message that you are responding to. > Doe

[Python-Dev] collections.idset and collections.iddict?

I occasionally need dictionaries or sets that use object identity rather than __hash__ to store items. Would it be appropriate to add these to the collections module? Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailm

Re: [Python-Dev] Two gcmodule patches

Barry Warsaw <[EMAIL PROTECTED]> wrote: > There are two patches on SF to add a couple of features to the gc > module. Skip wrote one (which I reviewed) and I wrote the other. > Neither is earth shattering, but they're helpful when debugging gc > issues. I have no major objections to either patch.

<    1   2   3   >