[Python-Dev] unscriptable?

> I dispute this. Indices aren't necessarily numeric > (think of an A-Z file), Python has recently added an __index__ slot which means "as an integer, and I really am an integer, I'm not just rounding like int(3.4) would do" So in the context of python, an index is numeric, whereas "subscript" ha

[Python-Dev] Encoding detection in the standard library?

David Wolever wrote: > IMO, encoding estimation is something that > many web programs will have to deal with, > so it might as well be built in; I would prefer > the option to run `text=input.encode('guess')` > (or something similar) than relying on an external > dependency or worse yet using a ha

Re: [Python-Dev] [Python-3000] Iterable String Redux (aka String ABC)

On 5/27/08, Benji York wrote: > Guido van Rossum wrote: > > Armin Ronacher wrote: > >> Basically *the* problematic situation with iterable strings is something > >> like > >> a `flatten` function that flattens out every iterable object except of > strings. > > I'm not against this, but so far

[Python-Dev] PEP 8 vs PEP 371: Additional Discussion

Guido van Rossum wrote: > I consider multiprocessing a new API -- while it bears > a superficial resemblance with the threading API the > similarities are just that, and it should not be > constrained by mistakes in that API. The justification for including it is precisely that it is *not* a new

[Python-Dev] Mini-Pep: An Empty String ABC

> So, apart from compatibility purposes, what is the > point currently of *not* directly subclassing str? To provide your own storage format, such as a views into existing data. Whether or not this is actually practical is a different question; plenty C code tends to assume it can use the interna

Re: [Python-Dev] [Python-3000] Betas today - I hope

On 6/12/08, Nick Coghlan <[EMAIL PROTECTED]> wrote: > documentation patch for the language reference ... > following categories: ... > 2. Method lookup MAY bypass __getattribute__, shadowing the attribute in > the instance dictionary MAY have ill effects. (slots such as __enter__ and > __exit__

[Python-Dev] Advice on numbers.py implementation of binary mixins.

Raymond Hettinger wrote: > PEP-3141 outlines an approach to writing binary > operators to allow the right operand to override > the operation if the left operand inherits the > operation from the ABC. > Here is my first approximation at how to write > them for the Integral mixins: > class Integr

[Python-Dev] Proposal: add odict to collections

The odict (as proposed here, ordered on time of key insertion) looks like a close match to the dlict needed by some of the optimization proposals. http://python.org/dev/peps/pep-0267/ -jJ ___ Python-Dev mailing list Python-Dev@python.org http://mail.pyt

[Python-Dev] www.python.org/doc and docs.python.org hotfixed

> For the search engine issue, is there any way we can tell robots to > ignore the rewrite rules so they see the broken links? (although even > that may not be ideal, since what we really want is to tell the robot > the link is broken, and provide the new alternative) I may be missing something ob

[Python-Dev] syntax change justification

Nick Coghlan's explanation of what justifies a syntax change (most of message http://mail.python.org/pipermail/python-dev/2008-October/082831.html ) should probably be added to the standard docs/FAQs somewhere. At the moment, I'm not sure exactly where, though. At the moment, the Developer FAQ (h

[Python-Dev] backporting tests [was: [Python-checkins] r66863 - python/trunk/Modules/posixmodule.c]

In http://mail.python.org/pipermail/python-dev/2008-October/082994.html Martin v. Löwis wrote: > So 2.6.0 will contain a lot of tests that have never been tested in > a wide variety of systems. Some are incorrect, and get fixed in 2.6.1, > and stay fixed afterwards. This is completely different fr

[Python-Dev] Looking for VCS usage scenarios

David Ripton wrote: > Time for average user to check out Python sources with bzr: 10 minutes > Time for average user to check out Python sources with git or hg: 1 minute > Time for average user's trivial patch to be reviewed and committed: 1 year > I love DVCS as much as the next guy, but check

[Python-Dev] Merging flow

Nick Coghlan wrote: > For now it looks like we might have to maintain 3.0 manually, with > svnmerge only helping out for trunk->2.6 and trunk->py3k Does it make the bookkeeping horrible if you merge from trunk straight to 3.0, and then blocked svnmerged changes from propagating? -jJ

[Python-Dev] #ifdef __cplusplus?

Alexander Belopolsky wrote: > 4. Should exported symbols be always declared in headers or is it ok > to just declare them as extern in .c files where they are used? Is the concern that moving them to a header makes them part of the API? In other words, does replacing PyObject * PyFile_From

Re: [Python-Dev] [Python-checkins] r68182 - in python/trunk: Lib/decimal.py Misc/NEWS

Our of curiousity, why are these constants for internal use only? Is there concern that people might start using "is", or is it just to keep the (beyond the spec) API small, or ...? -jJ On Fri, Jan 2, 2009 at 6:07 PM, mark. dickinson wrote: > Author: mark.dickinson > Date: Sat Jan 3 00:07:08 2

Re: [Python-Dev] [Python-checkins] cpython: #11572: improvements to copy module tests along with removal of old test suite

Why was the old test suite removed? Even if everything is covered by the test file (and that isn't clear from this checkin), I don't see anything wrong with a quick test that doesn't require loading the whole testing apparatus. (I would have no objection to including a comment saying that the maj

Re: [Python-Dev] [Python-checkins] cpython: Enhance Py_ARRAY_LENGTH(): fail at build time if the argument is not an array

On Wed, Sep 28, 2011 at 8:07 PM, Benjamin Peterson wrote: > 2011/9/28 victor.stinner : >> http://hg.python.org/cpython/rev/36fc514de7f0 >> changeset:   72512:36fc514de7f0 ... >> Thanks Rusty Russell for having written these amazing C macros! > Do we really need a new file? Why not pyport.h where

[Python-Dev] Case consistency [was: Re: [Python-checkins] cpython: Cleanup code: remove int/long idioms and simplify a while statement.]

Is there a reason to check for  if s[:5] == 'pass ' or s[:5] == 'PASS ': instead of if s[:5].lower() == 'pass' ? If so, it should be documented; otherwise, I would rather see the more inclusive form, that would also allow things like "Pass" -jJ On Sun, Oct 23, 2011 at 4:21 PM, florent.xi

[Python-Dev] PyUnicodeObject / PyASCIIObject questions

(see http://www.python.org/dev/peps/pep-0393/ and http://hg.python.org/cpython/file/6f097ff9ac04/Include/unicodeobject.h ) typedef struct { PyObject_HEAD Py_ssize_t length; Py_hash_t hash; struct { unsigned int interned:2;

Re: [Python-Dev] PyUnicodeObject / PyASCIIObject questions

On Tue, Dec 13, 2011 at 2:55 AM, "Martin v. Löwis" wrote: >> (1)  Why is PyObject_HEAD used instead of PyObject_VAR_HEAD? > The unicode object is not a var object. In a var object, tp_itemsize > gives the element size, which is not possible for unicode objects, > since the itemsize may vary by in

[Python-Dev] A new dict for Xmas?

> Greg Ewing wrote: >> Mark Shannon wrote: >>> I have a new dict implementation which allows sharing of keys between >>> objects of the same class. >> We already have the __slots__ mechanism for memory savings. >> Have you done any comparisons with that? > You can't make Python programmers use s

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

In http://mail.python.org/pipermail/python-dev/2011-December/115138.html, Christian Heimes pointed out that > ... we don't have to alter the outcome of hash ... We just need to reduce the > chance that > an attacker can produce collisions in the dict (and set?) I'll state it more strongly. hash

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

Steven D'Aprano (in ) wrote: > By compile-time, do you mean when the byte-code is compilated, i.e. just > before runtime, rather than a switch when compiling the Python executable from > source? No. I really mean when the C c

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

Paul McMillan in wrote: > Guido van Rossum wrote: >> Hm. I'm not sure I like the idea of extra arithmetic for every character >> being hashed. > the collision generator doesn't necessarily vary the length of the > string. Addi

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

Victor Stinner wrote in > If we want to protect a website against this attack for example, we must > suppose that the attacker can inject arbitrary data and can get > (indirectly) the result of hash(str) (e.g. with the represen

[Python-Dev] http://mail.python.org/pipermail/python-dev/2011-December/115172.html

In http://mail.python.org/pipermail/python-dev/2011-December/115172.html, P. J. Eby wrote: > On Sat, Dec 31, 2011 at 7:03 AM, Stephen J. Turnbull > wrote: >> While the dictionary probe has to start with a hash for backward >> compatibility reasons, is there a reason the overflow strategy for >>

Re: [Python-Dev] http://mail.python.org/pipermail/python-dev/2011-December/115172.html

On Sun, Jan 1, 2012 at 8:04 PM, Christian Heimes wrote: > Am 02.01.2012 01:37, schrieb Jim Jewett: >> Well, there is nothing wrong with switching to a different hash function >> after N >> collisions, rather than "in the first place".  The perturbation >> ef

Re: [Python-Dev] http://mail.python.org/pipermail/python-dev/2011-December/115172.html

On Sun, Jan 1, 2012 at 10:00 PM, PJ Eby wrote: > On Sun, Jan 1, 2012 at 7:37 PM, Jim Jewett wrote: >> Well, there is nothing wrong with switching to a different hash function >> after N >> collisions, rather than "in the first place".  The perturbation >> ef

Re: [Python-Dev] That depends on what the meaning of "is" is (was Re: http://mail.python.org/pipermail/python-dev/2011-December/115172.html)

On Mon, Jan 2, 2012 at 1:16 AM, PJ Eby wrote: > On Sun, Jan 1, 2012 at 10:28 PM, Jim Jewett wrote: >> >> Given the wording requiring a real dictionary, I would have assumed >> that it was OK (if perhaps not sensible) to do pointer arithmetic and >> access the

Re: [Python-Dev] That depends on what the meaning of "is" is (was Re: http://mail.python.org/pipermail/python-dev/2011-December/115172.html)

On Mon, Jan 2, 2012 at 7:16 PM, PJ Eby wrote: > On Mon, Jan 2, 2012 at 4:07 PM, Jim Jewett wrote: >> But the public header file < >> http://hg.python.org/cpython/file/3ed5a6030c9b/Include/dictobject.h > >> defines the typedef structs for PyDictEntry and _dictobject.

[Python-Dev] Proposed PEP on concurrent programming support

(I've added back python-ideas, because I think that is still the appropriate forum.) > A new > suite type - the ``transaction`` will be added to the language. The > suite will have the semantics discussed above: modifying an object in > the suite will trigger creation of a thread-local shallow

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

In http://mail.python.org/pipermail/python-dev/2012-January/115350.html, Mark Shannon wrote: > The minimal proposed change of seeding the hash from a global value (a > single memory read and an addition) will have such a minimal performance > effect that it will be undetectable even on the most no

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

In http://mail.python.org/pipermail/python-dev/2012-January/115368.html Stefan Behnel wrote: > Admittedly, this may require some adaptation for the PEP393 unicode memory > layout in order to produce identical hashes for all three representations > if they represent the same content. They SHOULD N

[Python-Dev] Is this safe enough? Re: [Python-checkins] cpython: _Py_Identifier are always ASCII strings

I realize that _Py_Identifier is a private name, and that PEP 3131 requires anything (except test cases) in the standard library to stick with ASCII ... but somehow, that feels like too long of a chain. I would prefer to see _Py_Identifier renamed to _Py_ASCII_Identifier, or at least a comment sta

Re: [Python-Dev] PEP for new dictionary implementation

On Thu, Feb 16, 2012 at 4:34 PM, "Martin v. Löwis" wrote: > Am 16.02.2012 19:24, schrieb Jim J. Jewett: >> PEP author Mark Shannon wrote >> (in >> http://mail.python.org/pipermail/python-dev/attachments/20120208/05be469a/attachment.txt): >>> ... allows ... (the ``__dict__`` attribute of an obje

Re: [Python-Dev] PEP for new dictionary implementation

On Fri, Feb 17, 2012 at 1:50 AM, "Martin v. Löwis" wrote: >>> Good idea. However, how do you track per-dict how large the >>> table is? [Or, rather, what is the highest index needed to store any values that are actually set for this instance.] > To determine whether it needs to grow the array, i

Re: [Python-Dev] [Python-checkins] peps: Switch back to named functions, since the Ellipsis version degenerated badly

On Wed, Feb 22, 2012 at 10:22 AM, nick.coghlan wrote: > +    in x = weakref.ref(target, report_destruction) > +    def report_destruction(obj): >         print("{} is being destroyed".format(obj)) > +If the repetition of the name seems especially annoying, then a throwaway > +name like ``f`` can

Re: [Python-Dev] [Python-checkins] cpython: Close #14205: dict lookup raises a RuntimeError if the dict is modified during

I do not believe the change set below is valid. As I read it, the new test verifies that one particular type of Nasty key will provoke a RuntimeError -- but that particular type already did so, by hitting the recursion limit. (It doesn't even really mutate the dict.) Meanwhile, the patch throws

Re: [Python-Dev] [Python-checkins] cpython (2.7): Fixes Issue 14234: fix for the previous commit, keep compilation when

Does this mean that if Python is updated before expat, python will compile out the expat randomization, and therefore not use if even after expat is updated? -jJ On Thu, Mar 15, 2012 at 2:01 PM, benjamin.peterson wrote: > http://hg.python.org/cpython/rev/ada6bfbeceb8 > changeset:   75699:ada6bfb

Re: [Python-Dev] [Python-checkins] cpython (3.2): attempt to fix asyncore buildbot failure

What does this verify? My assumption from the name (test_quick_connect) and the context (an asynchronous server) is that it is verifying the server can handle a certain level of load. Refusing the sockets should then be a failure, or at least a skipped test. Would the below fail even if asyncore

[Python-Dev] Who are the decimal volunteers? Re: [Python-checkins] cpython: Resize the coefficient to MPD_MINALLOC also if the requested size is below

I remember that one of the concerns with cdecimal was whether it could be maintained by anyone except Stefan (and a few people who were already overcommitted). If anyone (including absolute newbies) wants to step up, now would be a good time to get involved. A few starter questions, whose answer

[Python-Dev] PEP 418 glossary

I believe PEP 418 (or at least the discussion) would benefit greatly from a glossary to encourage people to use the same definitions. This is arguably the Definitions section, but it should move either near the end or (preferably) ahead of the Functions. It also needs to be greatly expanded. Her

[Python-Dev] (time) PEP 418 glossary V2

Glossary Absolute Time - A measurement of time since a specific Epoch_, typically far in the past. Civil Time is the most common example. Typically contrasted with a `Duration`_, as (now - epoch) is generally much larger than any duration that can be appropriately measured

Re: [Python-Dev] (time) PEP 418 glossary V2

On Tue, Apr 24, 2012 at 6:38 AM, Victor Stinner wrote: >> Monotonic >> - >> This is a particularly tricky term, as there are several subtly >> incompatible definitions in use. > Is it a definition for the glossary? One use case for a PEP is that someone who does *not* have a background

Re: [Python-Dev] [Python-checkins] peps: Note that ImportError will no longer be raised due to a missing __init__.py

On Thu, Apr 19, 2012 at 18:56, eric.smith wrote: > +Note that an ImportError will no longer be raised for a directory > +lacking an ``__init__.py`` file. Such a directory will now be imported > +as a namespace package, whereas in prior Python versions an > +ImportError would be raised. Given that

Re: [Python-Dev] PEP 362: 4th edition

On Sat, Jun 16, 2012 at 11:27 AM, Nick Coghlan wrote: > On Sat, Jun 16, 2012 at 1:56 PM, Jim J. Jewett wrote: >>    *Every* Parameter attribute is optional, even name. >>  (Think of  builtins, even if they aren't automatically >>supported yet.)   So go ahead and define some others >>th

Re: [Python-Dev] PEP 362: 4th edition

On Mon, Jun 18, 2012 at 10:37 AM, Yury Selivanov wrote: > Jim, > > On 2012-06-18, at 3:08 AM, Jim Jewett wrote: >> On Sat, Jun 16, 2012 at 11:27 AM, Nick Coghlan wrote: >>> On Sat, Jun 16, 2012 at 1:56 PM, Jim J. Jewett wrote: >>>>    Instead of defining

[Python-Dev] PEP 362 minor nits

I've limited this to minor issues, but kept python-dev in the loop because some are questions, rather than merely editorial. Based on: http://hg.python.org/peps/file/tip/pep-0362.txt view pep-0362.txt @ 4466:659639095ace Committing the latest changes to PEP 362 on behalf of Yury Selivanov. a

Re: [Python-Dev] PEP 362 minor nits

On Tue, Jun 19, 2012 at 11:53 AM, Yury Selivanov wrote: >> Based on:  http://hg.python.org/peps/file/tip/pep-0362.txt >> view pep-0362.txt @ 4466:659639095ace >> == >>   142 * args : tuple >>   143     Tuple of positional arguments values.  Dynamically computed from >>   144    

Re: [Python-Dev] PEP 362 minor nits

On Tue, Jun 19, 2012 at 2:10 PM, Yury Selivanov wrote: > On 2012-06-19, at 12:33 PM, Jim Jewett wrote: > >> On Tue, Jun 19, 2012 at 11:53 AM, Yury Selivanov >> wrote: >> >>>> Based on:  http://hg.python.org/peps/file/tip/pep-0362.txt >&g

Re: [Python-Dev] [Python-checkins] cpython: Close #15387: inspect.getmodulename() now uses a new

Why is inspect.getmoduleinfo() deprecated? Is it just to remove circular dependencies? FWIW, I much prefer an API like: tell_me_about(object) to one like: for test_data in (X, Y, Z): usable = tester(object, test_data) if valid(usable): return possible_result

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

On 11/20/12, Daniel Holth wrote: > On Tue, Nov 20, 2012 at 3:58 PM, Jim J. Jewett > wrote: >> Vinay Sajip reworded the 'Provides-Dist' definition to explicitly say: >> > The use of multiple names in this field *must not* be used for >> > bundling distributions together. It is intended for use w

[Python-Dev] Exceptions *must*? be old-style classes?

Phillip J. Eby wrote (in http://mail.python.org/pipermail/python-dev/2005-January/050854.html) > * Classic class support is a must; exceptions are still required to be > classic, and even if they weren't in 2.5, backward compatibility should be > provided for at least one release. The base of t

[Python-Dev] Deprecating modules (python-dev summary for early Dec, 2004)

> It was also agreed that deleting deprecated modules was not needed; it breaks > code and disk space is cheap. > It seems that no longer listing documentation and adding a deprecation > warning > is what is needed to properly deprecate a module. By no longer listing > documentation new progr

Re: [Python-Dev] Deprecating modules (python-dev summary for early Dec, 2004)

On Tue, 25 Jan 2005 16:21:34 -0600, Skip Montanaro <[EMAIL PROTECTED]> wrote: > > Jim> Would it make sense to add an attic (or even "deprecated") > Jim> directory to the end of sys.path, and move old modules there? This > Jim> would make the search for non-deprecated modules a bit fas

[Python-Dev] Re: [Python-checkins] python/dist/src/Python compile.c, 2.343, 2.344

On Wed, 09 Feb 2005 17:42:41 -0800, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Update of /cvsroot/python/python/dist/src/Python > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv31172 > > Modified Files: > compile.c > Log Message: > Remove the set conversion which didn't work wit

[Python-Dev] Prospective Peephole Transformation

Raymond Hettinger: > tried transforming the likes of "x in (1,2,3)" into "x in > frozenset([1,2,3])". >... There were substantial savings even if the set contained only a single entry. >... where x was non-hashable and it would raise a TypeError instead of > returning False as it should. I

[Python-Dev] @deprecated (was: Useful thread project for 2.5?)

Greg wished for: ... compiler recognition of "@deprecated" in doc comments. Michael Chermside suggested: = code = import warnings def deprecated(func): """This is a decorator which can be used to mark functions as deprecated. It will result in a warning b

[Python-Dev] comprehension abbreviation (was: Adding any() and all())

Barry: > Ping's suggested list comprehension abbreviation, i.e.: >[x in seq if x] == [x for x in seq if x] > might help. Note that the last x shouldn't have to be x. [x in seq if f(x)] is by far my most common syntax error, and [x for x in seq if f(x)] is always what I want in

[Python-Dev] Adding any() and all()

Guido van Rossum: > Whether to segregate these into a separate module: they are really a > very small amount of syntactic sugat, and I expect that in most cases, > instead of importing that module (which totally makes me lose my > context while editing) I would probably just write the extra line t

[Python-Dev] RE: code blocks using 'for' loops and generators

It may be time to PEP (or re-PEP), if only to clarify what people are actually asking for. Brian Sabbey's example from message http://mail.python.org/pipermail/python-dev/2005-March/052202.html *seems* reasonably clear, but I don't see how it relates in any way to "for" loops or generators, exce

[Python-Dev] Re: comprehension abbreviation (was: Adding any() and all())

Gareth McCaughan wrote: > Some bit of my brain is convinced that [x in stuff if condition] > is the Right Syntax and keeps making me type it even though > I know it doesn't work. (and I agree with Gareth) On Monday 2005-03-14 12:42, Eric Nieuwland wrote: > The full syntax is: > [ f(x) for x in s

[Python-Dev] Re: python/dist/src/Lib/distutils/command upload.py, 1.3, 1.4

On Tue, 22 Mar 2005 12:32:46 -0800, [EMAIL PROTECTED] wrote: > Don't set the Python version for sdist uploads. Why not? I realize that version is more important for pre-compiled extension modules, but it applies even to a pure python package. Source code that uses @decoration won't work in pyth

[Python-Dev] Re: python/dist/src/Lib/distutils/command upload.py, 1.3, 1.4

On Tue, 22 Mar 2005 18:00:50 -0500, "Fred L. Drake, Jr." <[EMAIL PROTECTED]> wrote: > On Tuesday 22 March 2005 16:09, Jim Jewett wrote: > > Why not? I realize that version is more important for pre-compiled > > extension modules, but it applies even to a pure py

[Python-Dev] @decoration of classes

Josiah Carlson: > I just noticed that decoration of classes was not included with the > @decoration syntax that made it into Python 2.4. ... > Is the fact that it didn't make it into 2.4 due to a pronouncement Yes, but it wasn't a permanent decision, and I don't think he used the magic word "pr

[Python-Dev] Re: switch statement

Michael Chermside wrote: > Now the pattern matching is more interesting, but again, I'd need to > see a proposed syntax for Python before I could begin to consider it. > If I understand it properly, pattern matching in Haskell relies > primarily on Haskell's excellent typing system, which is absen

[Python-Dev] defmacro (was: Anonymous blocks)

As best I can tell, the anonymous blocks are used to take care of boilerplate code without changing the scope -- exactly what macros are used for. The only difference I see is that in this case, the macros are limited to entire (possibly compound) statements. To make this more concrete, Gu

[Python-Dev] defmacro (was: Anonymous blocks)

Guido: > My problem with macros is actually more practical: Python's compiler > is too dumb. I am assuming that we want to be able to import macros > from other modules, and I am assuming that macros are expanded by the > compiler, not at run time; but the compiler doesn't follow imports ... Expa

[Python-Dev] defmacro (was: Anonymous blocks)

Michael Chermside: > There are lots of things one might want to replace within macros, from > identifiers to punctuation, but I'd be willing to live with just two of > them: expressions, and "series-of-statements" (that's almost the same as > a block). There are only two places I'd want to be able

Re: [Python-Dev] defmacro (was: Anonymous blocks)

On 4/25/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > It could also be done (though not as cleanly) by making macros act as > > import hooks. > Brrr. What about imports that aren't at the top level (e.g. inside a > function)? Bad style already. :D If you want to use the macro, you have to

[Python-Dev] Re: switch statement

M.-A. Lemburg wrote: > Having a simple switch statement > would enable writing very fast parsers in Python - ... > Instead of having one function call per token, you'd > only have a single dict lookup. > BTW, has anyone in this thread actually read the PEP 275 ? I haven't actually seen any use c

[Python-Dev] Re: anonymous blocks vs scope-collapse

Michael Hudson: > This proposal seems a bit like an effort to make generators good at > doing something that they aren't really intended -- or dare I say > suited? -- for. I think it is more an effort to use the right keyword, which has unfortunately already been claimed by generators (and li

[Python-Dev] Re: anonymous blocks vs scope-collapse

>> (2) Add a way to say "Make this function I'm calling use *my* locals >> and globals." This seems to meet all the agreed-upon-as-good use >> cases, but there is disagreement over how to sensibly write it. The >> calling function is the place that could get surprised, but people >> who want thu

[Python-Dev] scope-collapse

[Jim Jewett] >> >> (2) Add a way to say "Make this function I'm calling use *my* locals >> >> and globals." This seems to meet all the agreed-upon-as-good use >> >> cases, but there is disagreement over how to sensibly write it. [Guido] &g

[Python-Dev] defmacro (was: Anonymous blocks)

>> >> (3) Add macros. We still have to figure out how to limit their obfuscation. >> > nobody has given even a *remotely* >> > plausible mechanism for how exactly you would get code executed at >> > compile time. >> macros can (and *possibly* should) be evaluated at run-time. > We must still

Re: [Python-Dev] Re: scope-collapse (was: anonymous blocks)

On 4/26/05, Robert Brewer <[EMAIL PROTECTED]> wrote: > [Jim] > > Absolutely. Even giving up the XXX_FAST optimizations would > > still require new bytecode to not assume them. > I'm afraid I'm only familiar with CPython, but wouldn't callee locals > just map to XXX_FAST indices via the caller's c

[Python-Dev] anonymous blocks as scope-collapse: detailed proposal

Based on Guido's opinion that caller and callee should both be marked, I have used keywords 'include' and 'chunk'. I therefore call them "Chunks" and "Includers". Examples are based on (1) The common case of a simple resource manager. e.g. http://mail.python.org/pipermail/python-dev/2005-April

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

Nick Coghlan: > Python offers two variants on the basic iterative loop. >"for NAME in EXPR:" skips the finalisation step. At loop > completion, a well-behaved iterator may still contain additional values. > "for NAME from EXPR:" enforces finalisation of the iterator. > ... At loop complet

[Python-Dev] Anonymous blocks: Thunks or iterators?

Brian Sabbey: > It is possible to implement thunks without them creating their own > frame. They can reuse the frame of the surrounding function ... > The implementation just needs to take care > to save and restore members of the frame that get clobbered when the > thunk is running. Michael Hud

[Python-Dev] next(arg) was: Anonymous blocks: Thunks or iterators?

Guido van Rossum: > One [of many separate ideas in PEP 340] is turning generators > into more general coroutines: continue EXPR passes the expression > to the iterator's next() method ... I would have been very happy with that a week ago. Seeing the specific implementation changed my mind. The

[Python-Dev] Anonymous blocks: Thunks or iterators?

Guido van Rossum: > -- but it's more efficient, since calling yield doesn't create a frame. Neither should a thunk. > The other problem with thunks is that once we think of them as the > anonymous functions they are, we're pretty much forced to say that a > return statement in a thunk returns f

Re: [Python-Dev] Anonymous blocks: Thunks or iterators?

On 4/29/05, Brian Sabbey <[EMAIL PROTECTED]> wrote: > Jim Jewett wrote: > > The only members that need special attention are (f_code, f_lasti) > > and possibly (f_blockstack, f_iblock). > You don't even need to take care of f_code. The thunk and its surrounding

[Python-Dev] PEP 340: syntax suggestion - try opening(filename) as f:

Michael Spencer: > I don't know whether it's true for all the PEP 340 use cases, but the all the > current examples would read very naturally if the block-template could be > specified in an extended try statement: >> 1. A template for ensuring that a lock, acquired at the start of a >>

[Python-Dev] PEP 340 -- concept clarification

[Raymond Hettinger] >> Likewise, is it correct that "yield" is anti-parallel to the current >> meaning? Inside a generator, it returns control upwards to the caller. >> But inside a block-iterator, it pushes control downwards (?inwards) to >> the block it controls. Guido: > I have a hard time vis

Re: [Python-Dev] PEP 340 -- concept clarification

On 5/3/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > [Jim Jewett] ... > > With the block, every yield returns to a single designated callback. > > This callback had to be established at the same time the block was > > created, and must be textually inside it. (An

[Python-Dev] Breaking off Enhanced Iterators PEP from PEP 340

Enhanced Iterators: ... > When the *initial* call to __next__() receives an argument > that is not None, TypeError is raised; this is likely caused > by some logic error. This made sense when the (Block) Iterators were Resources, and the first __next__() was just to trigger the setup. It make

[Python-Dev] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)

Nick Coghlan wrote: > Josiah Carlson wrote: >> This has the benefit that an arbitrary block of code can be named, >> and a named TerminateBlock used to exit it. >> ... I suspect any such implementation is going to need to use >> exceptions for the guts of the flow control, even if that use isn'

[Python-Dev] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)

Nick Coghlan wrote: > "Loop on this iterator and finalise when done" would be written: >for item in itr: >process(item) >finally: >pass Greg Ewing wrote: > This is approaching things from the wrong end. The user of > an iterator shouldn't need to know or care whether it >

[Python-Dev] Merging PEP 310 and PEP 340-redux?

In http://mail.python.org/pipermail/python-dev/2005-May/053652.html Nick wrote: terminate = True VAR1 = stmt_enter() # Omit 'VAR1 =' if no 'as' clause try: try: BLOCK1 except TerminateBlock: raise # Disallow suppression of TerminateBlock

[Python-Dev] Pre-PEP: Unifying try-except and try-finally

[Guido] >>> Can I go ahead and approve this now? [Michael Hudson] >> While I see the cost of this PEP being pretty small, I see the benefit >> the same way too. [Guido] > Sure. Let me approve it and we'll see if someone cares enough to implement it. No one will scream if you approve it, but when

[Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation

Guido: > I don't like __true_int__ very much. Personally, > I'm fine with calling it __index__ index is OK, but is there a reason __integer__ would be rejected? __int__ roughly follows the low-level C implementation, and may do odd things on unusual input. __integer__ properly creates a concept

Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation

Is there a reason __integer__ would be rejected? Guido van Rossum answered: > Given the number of folks who misappreciate the difference between > __getattr__ and __getattribute__, I'm not sure I'd want to encourage > using abbreviated and full forms of the same term in the same context. > When c

[Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation

Travis wrote: > The patch adds a new API function int PyObject_AsIndex(obj) How did you decide between int and long? Why not ssize_t? Also, if index is being added as a builtin, should the failure result be changed? I'm thinking that this may become a replacement for isinstance(val, (int, lon

[Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation

Travis wrote: > The patch adds a new API function int PyObject_AsIndex(obj) How did you decide between int and long? Why not ssize_t? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: ht

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

On 2/14/06, Neil Schemenauer wrote: > People could spell it bytes(s.encode('latin-1')) in order to make it > work in 2.X. Guido wrote: > At the cost of an extra copying step. That sounds like an implementation issue. If it is important enough to matter, then why not just add some smarts to the

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

On 2/14/06, Neil Schemenauer wrote: > People could spell it bytes(s.encode('latin-1')) Guido wrote: > At the cost of an extra copying step. I asked: > ... why not just add some smarts to the bytes constructor? Guido wrote: > ... the VM usually keeps an extra reference > on the stack so the refc

[Python-Dev] Proposal: defaultdict

Adam Olsen asked: > ... d.getorset(key, func) would work in your use > cases? It is an improvement over setdefault, because it doesn't always evaluate the expensive func. (But why should every call have to pass in the function, when it is a property of the dictionary?) It doesn't actually *solve

[Python-Dev] conditional expressions - add parens?

Now that we have started to see conditional expressions ... I would like to see them parenthesized.  The parens aren't as important as they are with generator expressions, but ... they matter.From a recent checkin -- level = 0 if "absolute_import" in self.futures else -1Mentally, I can't hel

Re: [Python-Dev] conditional expressions - add parens?

On 3/6/06, Thomas Wouters <[EMAIL PROTECTED]> wrote: > On 3/6/06, Jim Jewett <[EMAIL PROTECTED]> wrote: > > level = 0 if "absolute_import" in self.futures else -1 > > Mentally, I can't help parsing that as "level = 0" plus > > commen

Re: [Python-Dev] conditional expressions - add parens?

On 3/7/06, Paul Moore <[EMAIL PROTECTED]> wrote: > The parentheses around genexps were (AFAICT) > different - without them, the grammar was ambiguous, > so some way of disambiguating was needed. The out-of-order evaluation is a very large change, because now we have a situation where normal parsi

<    1   2   3   >