Re: [Python-Dev] Py3k: Except clause syntax

tion details of the function that aren't relevant to the caller. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.

Re: [Python-Dev] GeneratorExit inheriting from Exception

n" will not catch all exceptions. My thoughts exactly. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not

Re: [Python-Dev] GeneratorExit inheriting from Exception

around making sure everyone's errors are standardised? :=) Also, "standard error" sounds like some sort of statistical term to me... -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam!

Re: [Python-Dev] GeneratorExit inheriting from Exception

things that you will almost always not want to catch, even in a top-level catch-almost-everything loop. So I'd leave these two out on their own. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam!

Re: [Python-Dev] Py3k: Except clause syntax

Tristan Seligmann wrote: > Greg Ewing <[EMAIL PROTECTED]> [2006-03-21 13:20:53 +1200]: > > Gareth McCaughan wrote: > > > > > >def f((x0,y0) as p0, (x1,y1) as p1): > For maximal utility, this would affect the calling signature of the > function, too: it

[Python-Dev] Pickling problems are hard to debug

There seems to be a need for better diagnostics when pickle encounters something that can't be pickled. Recently when attempting to pickle a rather large and complicated data structure, I got the following incomprehensible message: cPickle.PicklingError: args[0] from __newobj__ args has t

[Python-Dev] Class decorators

I've just been playing around with metaclasses, and I think I've stumbled across a reason for having class decorators as an alternative to metaclasses for some purposes. The metaclass I wrote was for the purpose of adding a class to a registry, the reason for which isn't important here. It worked,

Re: [Python-Dev] PySet API

Barry Warsaw wrote: > We're clearly going in circles here, and it's obvious we're not going to > agree. Would it perhaps help if there were a better API for using the iterator protocol from C code? Something that's as easy to use as the proposed set iterating API, but which uses the general ite

Re: [Python-Dev] Expose the array interface in Python 2.5?

Chris Barker wrote: > Can we have both? A defined interface, that existing code can be adapted > to provide, and a new C-Object, that future code can just use. If the > goal is to have as many extension types as possible use the same base > object, the sooner a standard object is provided the b

Re: [Python-Dev] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c

Travis E. Oliphant wrote: > I think this can be fixed easily by first checking the sequence slot for > a sq_concat function before calling PyNumber_InPlaceAdd. However, if this *is* fixed, it looks like it's going to break NumPy, in the sense that it will no longer be able to force an arithmetic

Re: [Python-Dev] PySet API

Barry Warsaw wrote: > My PySet_Clear() raises a SystemError > and returns -1 when the object is a frozen set. Isn't SystemError a bit drastic? TypeError would be sufficient here, surely. > > If PyObject_Clear() is implemented something like > > int PyObject_Clear(PyObject *o) > { > return (o

Re: [Python-Dev] Class decorators

Phillip J. Eby wrote: > It registers a function as the __metaclass__ by poking it into the f_locals > of the frame that's defining the class. That is stunningly brilliant! I'd nominate it for Hack of the Year if there were such an award. It's far too magical for me to feel like actually using i

Re: [Python-Dev] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c

Travis E. Oliphant wrote: > I can't imaging anybody relying on an in-place operations to return a > "different" object, but we could make the change and run all the > NumPy/SciPy tests to see what happens. I'm really thinking more about the non-inplace operators. If nb_add and sq_concat are col

Re: [Python-Dev] PySet API

Barry Warsaw wrote: > "Perhaps the PySet API can raise an error if it's ever called on > something that's not *exactly* a set? No subclassing allowed. > Shouldn't affect you, and should be an effective deterrent against > abuse of the kind that made the PyDict API an albatross." And perhaps in Py

Re: [Python-Dev] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c

Armin Rigo wrote: >>>> [].__add__(5) >TypeError: can only concatenate list (not "int") to list Would that be much of a loss? It doesn't really give you much more information than something like Unsupported operand types for '+': list, int and what it does give is based on the assumpt

Re: [Python-Dev] PySet API

Gareth McCaughan wrote: > For what it's worth[1], I think Raymond is absolutely on crack here. +1 on a good concrete set API from me, too. Being such similar types, sets should have about the same API richness as dicts, IMO. -- Greg ___ Python-Dev mai

Re: [Python-Dev] Class decorators

Phillip J. Eby wrote: > http://mail.python.org/pipermail/python-dev/2004-March/043462.html > Or more precisely, the subsequent discussion and examples convinced me that > putting class decorators on top of the class was bad for readability, vs. > putting them in the body just after the docstrin

Re: [Python-Dev] Class decorators

Fred L. Drake, Jr. wrote: > class Foo: > """Documentation is good.""" > > @class implements(IFoo) That's an interesting idea. It could be applied to functions, too: def myfunc(myargs): """Documentation is hoopy" @def biguglydecorator(longconvolutedarglist) Some

Re: [Python-Dev] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c

Armin Rigo wrote: > So if we provide a complete fix, [].__add__(x) will be modified to > return NotImplemented instead of raising TypeError if x is not a list, > and then [1,2,3]+array([4,5,6]) will fall back to array.__radd__() as > before. Ah, okay. That seems like it would work. -- Greg _

Re: [Python-Dev] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c

Tim Hochberg wrote: > Still, perhaps for Py3K it's worth considering > if PyNumber_InplaceAdd should only call __iadd__ and __add__, not > __radd__. Thus giving the target object complete control during inplace > adds. That's probably reasonable, although it would break the conceptual notion t

[Python-Dev] Name for python package repository

I just thought of a possible name for the Python package repository. We could call it the PIPE - Python Index of Packages and Extensions. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam

Re: [Python-Dev] pysqlite for 2.5?

evel of a reorganised package namespace, I don't think it would be out of place to reserve "db" for database stuff. It can always be renamed on import if it happens to conflict with anything in code, and I wouldn't object to not being able to have my own top-level package called &quo

Re: [Python-Dev] Class decorators

Phillip J. Eby wrote: > My comment above was only about readable *placement* of the decorators, not > the actual syntax. The placement is part of the syntax... -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carp

Re: [Python-Dev] PySet API

ariable length argument list instead of a single argument). Would that really buy you anything much over just making multiple PySet_Update() calls? Is it just syntactic sugar, or is there some optimisation you can do with multiple updates presented all at once? -

Re: [Python-Dev] Class decorators

d you provide this information? Still want class decorators, though. :-) BTW, the system I'm working on is a response to some hair-tearing problems I was experiencing trying to pickle some of my data, and also to address some disadvantages I see in using pickle for long-term data storage. I'

Re: [Python-Dev] pysqlite for 2.5?

with concurrency or large amounts of data that I know of. In fact, a Firebird interface might be an alternative worth considering for the library. It would have most of the advantages of SQLite without these disadvantages. -- Greg Ewing, Computer Science Dept, +--

Re: [Python-Dev] pysqlite for 2.5?

the hierarchy completely and going relational. Maybe a single dotted hierarchy of package names is too restrictive? Should we be able to import things by specifying attributes instead of a pathname? import db where db.stdlib == True and db.language == "SQL" \ and db.interface

Re: [Python-Dev] Class decorators

want them inherited) for large amounts of information that wouldn't comfortably fit up the top. That's an extra degree of freedom that we don't have with functions. - - - - - [1] Actually I would probably give it one optional argument, the name to register

Re: [Python-Dev] pysqlite for 2.5?

oint! Still, the fact remains that it's not a well-known abbreviation for *email*. :-) -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch,

Re: [Python-Dev] pysqlite for 2.5?

Fred L. Drake, Jr. wrote: > On Wednesday 29 March 2006 21:55, Greg Ewing wrote: > >import db where db.stdlib == True and db.language == "SQL" \ > > and db.interface == "DBAPI2.0" > > While we're at it, we could spell import "select

Re: [Python-Dev] Class decorators

Jack Diederich wrote: > Classes have a unique property in that they are the easiest way to make > little namespaces in python. For a while now, I've been wondering whether it would be worth having a construct purely for creating little namespaces, instead of abusing a class for this. I've been t

Re: [Python-Dev] Class decorators

Phillip J. Eby wrote: > Are you actually *using* this IOClass thing, or is this just a > hypothetical proposal? I'm using it. It's not hypothetical. Putting all the info I want in the decorator itself wouldn't be very nice in my case, or at least that's my opinion. One issue is that I'm also ab

Re: [Python-Dev] building sql queries in python

Thomas Wouters wrote: > > Have you looked at SqlObject? (and its associated modules > sqlobject.sqlbuilder in particular) > > SQLAlchemy (www.sqlalchemy.org ) is also > nice, in particular for more complex setups. > > There's plenty of ways to reliably and sa

Re: [Python-Dev] Class decorators

Raymond Hettinger wrote: > FWIW, I do not consider it an abuse to use a class to create a small > namespace. Essentially that is what it is for -- it matters not whether > the class has no methods. Two problems with that: * The word "class" in front of it is a misnomer if you've no intentio

Re: [Python-Dev] pysqlite for 2.5?

Fredrik Lundh wrote: > Greg Ewing wrote: > > > Firebird could be a solution to this. > > so a library that doesn't support multiple independent > readers/writers on a single file at all is much better > than one that does, Where do you get that from? Firebird supp

Re: [Python-Dev] pysqlite for 2.5?

Fredrik Lundh wrote: > not according to the documentation (which says that the embedded library locks > the database file, to prevent other independent processes from accessing the > data). I think that means other *non-Firebird* processes. Firebird itself uses a system of file locks and transac

Re: [Python-Dev] pysqlite for 2.5?

M.-A. Lemburg wrote: > I don't really care about the name, but please be aware that > you are talking about adding a *very* popular module name to > the top-level Python namespace if you go for "db" or "database". This would only be an issue for an application that had a private module calle db,

Re: [Python-Dev] reference leaks, __del__, and annotations

Jim Jewett wrote: > The checkins list has been struggling with generator reference leaks; > the latest conclusion was that some are unavoidable because of __del__ > cycles. That sort of defeats the purpose of resource managers. Seems to me we need a whole new approach to finalization that's frie

Re: [Python-Dev] reference leaks, __del__, and annotations

Nick Coghlan wrote: > Generators are even more special, in that they only require finalisation in > the first place if they're stopped on a yield statement inside a try-finally > block. I find it rather worrying that there could be a few rare cases in which my generators cause memory leaks, thr

Re: [Python-Dev] reference leaks, __del__, and annotations

Nick Coghlan wrote: > from contextlib import closing > > with closing(itr): ># Use the iterator in here as you wish ># secure in the knowledge it will be ># cleaned up promptly when you are done ># whether it is a file, a generator or ># something with a database connection >

Re: [Python-Dev] reference leaks, __del__, and annotations

Michael Hudson wrote: > And if we want to have a version of __del__ that can't reference > 'self', we have it already: weakrefs with callbacks. Does that actually work at the moment? Last I heard, there was some issue with gc and weakref callbacks as well. Has that been reso

Re: [Python-Dev] [Python-checkins] r43545 - in python/trunk: Doc/lib/libcalendar.tex Lib/calendar.py

Walter Dörwald wrote: > OK, the property setter does a "% 7" now. (But the global > setfirstweekday() still does a range check). Wouldn't it be better for the setter to raise an exception if it's out of range? It probably indicates a bug in the caller's code. -

Re: [Python-Dev] reference leaks, __del__, and annotations

ere so that the callback is reachable, that references enough stuff to clean up after the generator, without referencing the generator itself? -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | C

Re: [Python-Dev] [Python-checkins] r43545 - in python/trunk: Doc/lib/libcalendar.tex Lib/calendar.py

Walter Dörwald wrote: > Greg Ewing wrote: > >> Wouldn't it be better for the setter to raise an exception >> if it's out of range? It probably indicates a bug in the >> caller's code. > > The day before Monday is -1, so it adds a little convenience.

Re: [Python-Dev] reference leaks, __del__, and annotations

Tim Peters wrote: > A problem is that the variant semantics also seem pretty arbitrary ;-), > and there's a dearth of compelling use cases to guide a decision. At the time I think I suggested that it would be reasonable if weakref callbacks were guaranteed to be called as long as they weren't tras

Re: [Python-Dev] reference leaks, __del__, and annotations

Neil Schemenauer wrote: > I think so but it depends on what the finalizer needs to reference. That's really what I'm asking -- what *does* a generator finaliser need to reference? Or does it depend on what the generator's code does? -- Greg ___ Python-

Re: [Python-Dev] reference leaks, __del__, and annotations

James Y Knight wrote: > All right, then, you could use the top bit of the ob_refcnt field. > There's no way to possibly have 2**32 objects on a 32bit system anyhow. That would slow down every Py_INCREF and Py_DECREF, which would need to be careful to exclude the top bit from their operations.

Re: [Python-Dev] reference leaks, __del__, and annotations

Martin v. Löwis wrote: > Of this kind, we have several spare bits: there are atleast two bits > in the ob_type field, And that would require changing all code that dereferenced the ob_type field! This would be much worse -- at least Py_INCREF and Py_DECREF are macros... -- Greg _

Re: [Python-Dev] Should issubclass() be more like isinstance()?

Crutcher Dunnavant wrote: > A) issubclass() throws a TypeError if the object being checked is not > a class, which seems very strange. If I ever pass a non-class to issubclass() it's almost certainly a bug in my code, and I'd want to know about it. On the rare occasions when I don't want this, I

Re: [Python-Dev] tally (and other accumulators)

Jess Austin wrote: > I'll go > so far as to suggest that the existence of groupby() obviates the > proposed tally(). Except that it requires building a list of values in each group when all you want at the end is the length of the list. -- Greg ___ Pyth

[Python-Dev] elementtree in stdlib

ee containing a module called ElementTree containing a class called ElementTree is just too confusing for words! -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand

Re: [Python-Dev] elementtree in stdlib

naming of things added to the stdlib, consistency of naming is never going to improve. Or should this wait for Py3k? -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New

Re: [Python-Dev] elementtree in stdlib

Trent Mick wrote: > try: > import xml.etree.ElementTree as ET # in python >=2.5 > except ImportError: >... etc ad nauseam For situations like this I've thought it might be handy to be able to say import xml.etree.ElementTree or cElementTree or \ elementtree.Eleme

Re: [Python-Dev] elementtree in stdlib

Georg Brandl wrote: > Suppose I wanted to implement that, what would be the best strategy > to follow: > - change handling of IMPORT_NAME and IMPORT_FROM in ceval.c > - emit different bytecodes in compile.c > - directly create TryExcept AST nodes in ast.c I'd probably go for the third option. Isn

Re: [Python-Dev] pdb segfaults in 2.5 trunk?

Tim Peters wrote: > The PyObject_ memory family is generally faster and more > memory-efficient for small allocations than the PyMem_ memory family. > Lines of source code, and encoding strings, are usually small enough > to exploit that. The "ob" in obmalloc.c doesn't really have anything > to

Re: [Python-Dev] [Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS

umption that you're going to see the module name as well. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.

Re: [Python-Dev] PEP 359: The "make" Statement

Steven Bethard wrote: >make : > I don't like the position of the name being defined. It should be straight after the opening keyword, as with 'def' and 'class'. This makes it much easier to search for definitions of things, both by eyeball and editor search functions, etc. -- Greg

Re: [Python-Dev] a flattening operator?

Josiah Carlson wrote: > One major problem with this is that except for function calls, * is the > multiplication operator, which operates on two arguments. *foo is an > operation on a single argument, and without parenthesis, would be > ambiguously parsed. No, it wouldn't. There's no problem in

Re: [Python-Dev] adding Construct to the standard library?

Travis Oliphant wrote: > For what it's worth, NumPy also defines a data-type object which it > uses to describe the fundamental data-type of an array. In the context > of this thread it is also yet another way to describe a binary-packed > structure in Python. Maybe there should be a separat

Re: [Python-Dev] Raising objections (was: setuptools in the stdlib)

Anthony Baxter wrote: > I started refactoring some of the ugliness out of the internals of > distutils last year, but was completely stymied by the demand that no > existing setup.py scripts be broken. Instead of trying to fix distutils, maybe it would be better to start afresh with a new packa

Re: [Python-Dev] Raising objections

Martin v. Löwis wrote: > If distutils is now abandoned and replaced with > something else, the same story will happen again: the developers will > run away, the package gets abandoned, Seems to me that if we had something with a clean design that was easy to understand, maintain and extend, that

Re: [Python-Dev] 2.5a1 Performance

Terry Reedy wrote: > I took a look. The only thing that puzzles me is 'warp factor', which > appears exactly once. It's been put there via time machine in connection with the dilithium crystal support in that will be added in Python 7.0. You don't need to worry about it yet. -- Greg __

Re: [Python-Dev] Raising objections

Fredrik Lundh wrote: > (distutils and setuptools are over 15000 lines of code, according to sloc- > count. Ye cats! That's a *seriously* big ball of mud. I just checked, and the whole of Pyrex is only 17000 lines. -- Greg ___ Python-Dev mailing list Py

Re: [Python-Dev] Raising objections

Phillip J. Eby wrote: > If they have Pyrex installed, setuptools uses > Pyrex to rebuild the .c from the .pyx. I hope it would only do this if the .pyx was newer than the .c. It's probably not a good idea to assume that just because Pyrex is around, the user wants to use it in all cases. He migh

Re: [Python-Dev] Raising objections

Anthony Baxter wrote: >>http://www.joelonsoftware.com/articles/fog69.html From what I remember, he didn't actually say that you should never rewrite anything, but that if you do, you need to be prepared for a very long period of time when nothing new is working, and that *if you are a co

Re: [Python-Dev] Raising objections

Guido van Rossum wrote: > I'd rather recommend the approach that Joel suggests for truly large > systems: refactoring smaller components while keeping the overall > structure intact. That's fine as long as the overall structure isn't the very thing that's wrong and needs to be fixed. Incremental

Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)

Guido van Rossum wrote: > The "resources" name is actually quite a common meme; I believe it goes back to the original Macintosh, which was the first and only computer in the world to have files with something called a "resource fork". The resource fork contained pieces of data called "resources"

Re: [Python-Dev] Distutils thoughts

While we're on the subject of distutils revision, here are a few things I've encountered about distutils which seem less than desirable. * There doesn't seem to be a way of supplying options on the command line for anything except the top-level command. Sometimes, e.g. I want to do an "insta

Re: [Python-Dev] proposal: evaluated string

tomer filiba wrote: > first of all -- i know there's a bunch of templating engines, but i > think it should be a built-in feature of the language. One fairly serious drawback to this idea is that it inhibits i18n. For security reasons it has to be implemented at compile time and only work on str

Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)

Martin v. Löwis wrote: > Some libraries (not necessarily in Python) have gone the path of > providing a "unified" API for all kinds of file stream access, > e.g. in KDE, any tool can open files over many protocols, without > the storage being mounted locally. Maybe a compromise would be to provid

Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)

Guido van Rossum wrote: > You > can't blame KDE for providing mechanisms that only work in the KDE > world. It's fine for Python to provide Python-specific solutions for > issues that have no cross-platform native solution. Also keep in mind that we're talking about resources used internally by th

Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)

Martin v. Löwis wrote: > Greg Ewing wrote: > >>>The "resources" name is actually quite a common meme; >> >>I believe it goes back to the original Macintosh, > > I can believe that history. Still, I thought a resource > is something you can exhaust;

Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)

Martin v. Löwis wrote: > I can readily believe that package authors indeed see this as > a simplification, but I also see an increased burden on system > admins in return. There are two conflicting desires here. Package authors don't want to have to make M different kinds of package for M differe

Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)

Phillip J. Eby wrote: > By now, however, the term is popularly used with GUI toolkits of all > kinds to mean essentially read-only data files that are required by a > program or library to function, but which are not directly part of the > code. It's just occurred to me that there's another th

Re: [Python-Dev] setuptools in 2.5.

Phillip J. Eby wrote: > You seem to believe that there are other > things more important than making things Just Work for this audience. While it's clearly a good thing when something "just works", I don't think that this should be the only goal. Just as important to my mind -- probably even more

Re: [Python-Dev] setuptools in 2.5.

Phillip J. Eby wrote: > So, this is a nice > example of how complex it can be to extend the distutils in ways that don't > break random popular packages. It's probably also an example of what happens when something doesn't have a well-documented extension interface -- nobody can tell what's an i

Re: [Python-Dev] Distutils thoughts

Paul Moore wrote: > I do things like > > python setup.py build --compiler=mingw32 bdist_wininst > > which seem to work for me. Is that any help? Possibly. I'll have to try it next time I have the problem and see. BTW, does that do anything different from python setup.py build --compil

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

Nick Coghlan wrote: > During implementation, the meanings of "context" and "context manager" were > swapped from the meanings in the approved PEP, leading to the current > situation where decimal.Context is actually not, in fact, a context. That's rather disappointing. I *liked* the way that de

Re: [Python-Dev] setuptools in 2.5.

Paul Moore wrote: > Well, having 2 versions of a module installed and > knowing that which one is in use depends on require calls which get > issued at runtime worries me far more. There's also the problem of having module A which requires version 2.0 or earlier of Z, and B which requires 2.1 or l

Re: [Python-Dev] Distutils thoughts

Thomas Heller wrote: > The best solution is to configure the mingw32 compiler in the distutils > configuration file. That's the same conclusion I came to. But it's unintuitive that you can't also do the same thing using command line options, or if you can, it's not obvious how to do it. -- Greg

Re: [Python-Dev] [Python-3000-checkins] r45617 - in python/branches/p3yk/Lib/plat-mac/lib-scriptpackages: CodeWarrior/CodeWarrior_suite.py CodeWarrior/__init__.py Explorer/__init__.py Finder/Container

Thomas Wouters wrote: > > On 4/21/06, *guido.van.rossum* > wrote: > > somehow changing "import foo" into "from . import foo" ... > caused things to break. Bah. > > Hm, this is possibly a flaw in the explicit relative import mechanism. I don't

Re: [Python-Dev] Google Summer of Code proposal: improvement of long int and adding new types/modules.

Alex Martelli wrote: > GMP is covered by LGPL, so must any such derivative work But the wrapper is just using GMP as a library, so it shouldn't be infected with LGPLness, should it? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

A.M. Kuchling wrote: > Does this detail matter to users of the Decimal module, though? Those > users may well be thinking using the term 'context'. Seems to me the most straightforward term should be applied to the object that users are most likely to know about and use. The term "context" is fa

Re: [Python-Dev] Google Summer of Code proposal: improvement of long int and adding new types/modules.

Alex Martelli wrote: > gmpy.c > #include's gmp.h and uses (==expands) some of the C macros there > defined -- doesn't that make gmpy.o a derived work of gmp.h? Assuming that gmp.h is the header which defines the public interface of the gmp library, any code which uses it as a library will be inclu

Re: [Python-Dev] elimination of scope bleeding of iteration variables

Nick Coghlan wrote: > However, the scoping of for loop > variables won't change, as the current behaviour is essential for search > loops > that use a break statement to terminate the loop when the item is found. It occurs to me that there's a middle ground here: leave the loop variable scope

Re: [Python-Dev] More on contextlib - adding back a contextmanager decorator

Guido van Rossum wrote: > I believe the context API design has gotten totally out of hand. My thoughts exactly! > I have a counter-proposal: let's drop __context__... would it > really be such a big deal to let the user make an explicit call to > some appropriately named method? Another possibi

Re: [Python-Dev] More on contextlib - adding back a contextmanager decorator

Nick Coghlan wrote: > the context expression in the with > statement produces a context manager with __enter__ and __exit__ methods > which set up and tear down a managed context for the body of the with > statement. This is very similar to your later suggestion of context > guard and guarded c

Re: [Python-Dev] elimination of scope bleeding ofiteration variables

Delaney, Timothy (Tim) wrote: > So would this also be a SyntaxError? > > for x in stuff: > x = somethingelse That would be something to be debated. I don't really mind much one way or the other. -- Greg ___ Python-Dev mailing list Python-D

Re: [Python-Dev] PEP 3102: Keyword-only arguments

Terry Reedy wrote: > my way to call your example (given the data in separate variables): > make_person(name, age, phone, location) > your way: > make_person(name=name, age=age, phone=phone, location = location) For situations like that, I've sometimes thought it would be useful to be able to

Re: [Python-Dev] elimination of scope bleeding ofiteration variables

Josiah Carlson wrote: > for line in lines: > line = line.rstrip() > ... > > I'm generally -0 on the "raise a SyntaxError" in this particular case, That's a good point. I'm inclined to agree. I think I might have even done something like that recently, but I can't remember the

Re: [Python-Dev] PEP 3102: Keyword-only arguments

Guido van Rossum wrote: > On 5/2/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > >make_person(=name, =age, =phone, =location) > > And even with Terry's use case quoted I can't make out what you meant > that to do. I meant it to do the same thing as mak

Re: [Python-Dev] PEP 3102: Keyword-only arguments

ere there are literally dozens of potential arguments to many of the constructors. The only sane way to deal with that is for them to be keyword-only, at least conceptually if not in actual implementation. -- Greg Ewing, Computer Science Dept, +--+ U

Re: [Python-Dev] Alternative path suggestion

Mike Orr wrote: > The main difficulty with this approach is it's so radical. It would > require a serious champion to convince people it's as good as our > tried-and-true strings. Another thing you would need to do is implement it for some of the less Unix-like path syntaxes, such as Classic Mac

Re: [Python-Dev] Alternative path suggestion

Nick Coghlan wrote: > Similarly, I would separate out the extension to a distinct attribute, as it > too uses a different separator from the normal path elements ('.' most > places, > but '/' on RISC OS, for example) -1. What constitutes "the extension" is not well-defined in all cases. What a

Re: [Python-Dev] PEP 3102: Keyword-only arguments

Terry Reedy wrote: > The dispute is about the sensibility and > politeness of requiring a small fixed number of required, no-default args > to be passed by name only There seems to be some confusion between two different subthreads here. BJörn Lindqvist seemed to be saying that instead of my sug

Re: [Python-Dev] Python sprint mechanics

Tim Peters wrote: > Instead it would make best sense for each > sprint project to work in its own branch, something SVN makes very > easy, but only for those who _can_ commit. There's no way of restricting commit privileges to a particular branch? -- Greg _

Re: [Python-Dev] Alternative path suggestion

Nick Coghlan wrote: > So I suggest splitting the internal data into 'path elements separated > by os.sep', 'name elements separated by os.extsep' What bothers me about that is that in many systems there isn't any formal notion of an "extension", just a convention used by some applications. Just

Re: [Python-Dev] Alternative path suggestion

Mike Orr wrote: > How do you do slicing and joining? If Path subclasses object, it > could be done there like in the first example. But if Path subclasses > string, Er, hang on, I thought the idea was that it wouldn't subclass either tuple *or* str, but would be a new class all of its own. Tha

Re: [Python-Dev] Alternative path suggestion

Edward Loper wrote: > If one of the path segments contained a path-splitting character, > should it automatically get quoted? No, an exception should be raised if you try to construct a Path object containing such a name. No such object could exist in the file system, so there's no point in bei

Re: [Python-Dev] PEP 3102: Keyword-only arguments

BJörn Lindqvist wrote: > But IMHO, your design is broken if you need > to send dozens of arguments to any function or method. My design allows property values to be specified using keywords in the constructor. You typically only use a few of them in any given call, but there are a large number of

<    17   18   19   20   21   22   23   24   25   >