Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
[snip lexical scoping option]
> Now i think this is a little bit weird, because the statement
> "var b = 4" in an outer scope changes the meaning of "b" in an
> inner scope. But it does have the virtue of retaining behaviour
> compatible with today's Python,
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
>
> > What I asked before, and what I'd like to ask again, is if there are any
> > _nontrivial uses_ of lexically nested scopes which are made cumbersome
> > by our inability to write to paren
Armin Rigo <[EMAIL PROTECTED]> wrote:
>
> Hi Josiah,
>
> On Fri, Jun 30, 2006 at 01:27:24PM -0700, Josiah Carlson wrote:
> > I'll just have to gracefully degrade functionality for older Pythons.
>
> More precisely, the bug shows up because in
>
> wh
"tomer filiba" <[EMAIL PROTECTED]> wrote:
> weakattr (weak attributes) are attributes that are weakly referenced
> by their containing object. they are very useful for cyclic references --
> an object that holds a reference to itself.
I like the added functionality offered with weakattrs as defin
Talin <[EMAIL PROTECTED]> wrote:
> Here's another stab at the "explicit freezing" school of thought on the
> switch semantics. The idea is to borrow the freeze protocol and apply it
> to functions.
-1 . Freezing was previously questionably useful in the realm of
general data structures. Using
Greg Ewing <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > If the only code that benefits from such changes are "very *simple*",
> > then I think that says something about its necessity.
>
> The point is that they're only "very simple&qu
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>
> On 7/3/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> >
> > Greg Ewing <[EMAIL PROTECTED]> wrote:
> > > Josiah Carlson wrote:
> > > > If the only code that benefits from such ch
"Bill Chiles" <[EMAIL PROTECTED]> wrote:
>
> For Common Lispers and probably Schemers, Python has some surprising
> semantics around scope and lifetime extent of variables. Three that
> leap out at me are:
One thing to remember is that Python is not Scheme/Lisp. It borrows
some ideas from Sche
Donovan Baarda <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > Donovan Baarda <[EMAIL PROTECTED]> wrote:
> >
> >>Nick Coghlan wrote:
> >>
> >>>Donovan Baarda wrote:
> [...]
> >>But isn't a function just a deferred e
Nick Coghlan wrote:
>
> Guido van Rossum wrote:
> > But as long as we are describing the
> > present state we should call a spade a spade, etc.
>
> I guess I take a syntactic view of the status quo, because, while
> lambdas may be implemented as anonymous functions, the current syntax
> doesn'
Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Jp Calderone wrote:
> > If you use vars(self).update(locals()), it even looks halfway
> > pleasant ;) I'm not sure what python-dev's current opinion of
> > vars(obj) is though (I'm hoping someone'll tell me).
> >
> > Of course, both of these fall over fo
"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > Now, don't get me wrong, definining __slots__ can be a pain in the
> > tookus, but with a proper metaclass, that metaclass can define the
> > __slots__ attribu
Just because not all cars are used as vehicles, does that mean that cars
are not vehicles?
There may be cases where the object being managed is not a resource
per-se, but that doesn't mean that the mechanism is misnamed as a
'resource manager'; it's just the most common use case that any of us
ha
Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On 7/7/05, François Pinard <[EMAIL PROTECTED]> wrote:
> > [Guido van Rossum]
> >
> > > I even wonder if else-clauses on for/while were a good idea.
> >
> > I surely find them useful, and see them as a Python originality (a
> > welcome one).
>
> T
Andrew Durdin <[EMAIL PROTECTED]> wrote:
>
> On 7/7/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >
> > I don't think so. It smells too much of DWIM, which is very unpythonic.
> > EIBTI.
>
> In what way? The scheme described is explicit, and consistently
> applied to all triple-quoted stri
Andrew Durdin <[EMAIL PROTECTED]> wrote:
>
> On 7/11/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> >
> > You are wrong. Current string literals are explicit. They are what you
> > type.
>
> No they are not:
Apparently my disclaimer of "excep
Brett Cannon <[EMAIL PROTECTED]> wrote:
>
> On 7/30/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> >
> > Brett Cannon <[EMAIL PROTECTED]> wrote:
> >
> > > > +-- Warning
> > > > +-- DeprecationWarning
> &g
Your email is off-topic for python-dev, which is for the development OF
Python. Repost your question on python-list.
- Josiah
Joseh Martins <[EMAIL PROTECTED]> wrote:
>
> Hello Everybody,
>
> I´m a beginner in python dev..
>
> Well, i need to implement a external ping command and get the r
For 2.5a1...
Some exposure of _PyLong_AsByteArray() and _PyLong_FromByteArray() to
Python. There was a discussion about this almost a year ago
(http://python.org/sf/1023290), and no mechanism (struct format code
addition, binascii.tolong/fromlong, long.tostring/fromstring, ...)
actually made it in
Steven Bethard <[EMAIL PROTECTED]> wrote:
>
> Martin v. Löwis wrote:
> > So I would propose the syntax
> >
> > lst.sort(key=virtual.lower) # where virtual is functional.virtual
>
> Shane Hathaway wrote:
> > class virtual:
> > def __getattr__(self, name):
> > return lambda obj: g
Steven Bethard <[EMAIL PROTECTED]> wrote:
> I agree that an operator.methodcaller() shouldn't try to support
> multiple methods. OTOH, the syntax
> methodcall.method(*args, **kwargs)
> doesn't really lend itself to multiple methods either.
But that's OK, we don't want to be calling multiple
"Terry Reedy" <[EMAIL PROTECTED]> wrote:
>
> Can str.find be listed in PEP 3000 (under builtins) for removal?
> Would anyone really object?
I would object to the removal of str.find() . In fact, older versions
of Python which only allowed for single-character 'x in str' containment
tests offere
"Terry Reedy" <[EMAIL PROTECTED]> wrote:
>
> "Josiah Carlson" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> >
> > "Terry Reedy" <[EMAIL PROTECTED]> wrote:
> >>
> >> Can str.find be liste
Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On 8/26/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > Taking a look at the commits that Guido did way back in 1993, he doesn't
> > mention why he added .find, only that he did. Maybe it was another of
>
Donovan Baarda <[EMAIL PROTECTED]> wrote:
>
> On Sat, 2005-08-27 at 10:16 -0700, Josiah Carlson wrote:
> > Guido van Rossum <[EMAIL PROTECTED]> wrote:
> [...]
> > Oh, there's a good thing to bring up; regular expressions! re.search
> > returns a mat
Steve Holden <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> > Donovan Baarda <[EMAIL PROTECTED]> wrote:
> [...]
> >
> > One thing that has gotten my underwear in a twist is that no one has
> > really offered up a transition mechanism from &q
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote:
> [Guido]
> > Another observation: despite the derogatory remarks about regular
> > expressions, they have one thing going for them: they provide a higher
> > level of abstraction for string parsing, which this is all about.
> > (They are higher level
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote:
> As promised, here is a full set of real-world comparative code
> transformations using str.partition(). The patch isn't intended to be
> applied; rather, it is here to test/demonstrate whether the new
> construct offers benefits under a variety of u
Pierre Barbier de Reuille <[EMAIL PROTECTED]> wrote:
> Well, I want to come back on a point that wasn't discussed. I only found
> one positive comment here :
> http://mail.python.org/pipermail/python-dev/2005-August/055775.html
You apparently haven't been reading python-dev for around 36 hours,
b
Tim Peters <[EMAIL PROTECTED]> wrote:
>
> Anyone remember why setdefault's second argument is optional?
>
> >>> d = {}
> >>> d.setdefault(666)
> >>> d
> {666: None}
For quick reference for other people, d.setdefault(key [, value])
returns the value that is currently there, or just assigned. T
Pierre Barbier de Reuille <[EMAIL PROTECTED]> wrote:
> Well, what it does is exactly what I tought, you can express most of the
> use-cases of partition with:
>
> head, sep, tail = s.partition(sep)
> if not sep:
> #do something when it does not work
> else:
> #do something when it works
>
>
[EMAIL PROTECTED] wrote:
> Substr didn't copy as partition() will have to, won't many of uses of
> partition() end up being O(N^2)?
Yes. But if you look at most cases provided for in the standard library,
that isn't an issue. In the case where it becomes an issue, it is
generally because a user
Steve Holden <[EMAIL PROTECTED]> wrote:
>
> Guido van Rossum wrote:
> > On 8/30/05, Andrew Durdin <[EMAIL PROTECTED]> wrote:
> [confusion]
> >
> >
> > Hm. The example is poorly chosen because it's an end case. The
> > invariant for both is (I'd hope!)
> >
> > "".join(s.partition()) == s == "
Steve Holden <[EMAIL PROTECTED]> wrote:
>
> Fredrik Lundh wrote:
> > the problem isn't the time it takes to unpack the return value, the problem
> > is that
> > it takes time to create the substrings that you don't need.
> >
> Indeed, and therefore the performance of rpartition is likely to ge
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
>
> > A bit of free thought brings me to the (half-baked) idea that if string
> > methods accepted any object which conformed to the buffer interface;
> > mmap, buffer, array, ... insta
[EMAIL PROTECTED] wrote:
> >> I'm skeptical about performance as well, but not for that reason. A
> >> string object can have a referent field. If not NULL, it refers to
> >> another string object which is INCREFed in the usual way. At string
> >> deallocation, if the referent i
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote:
>
> [Jonny Reichwald]
> > I would like to suggest a small enhancement to str.strip().
> > By expanding its current form, where it only takes a char list, to
> > taking any list containing either char lists or string lists, it is
> > possible to remov
Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 9/6/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > A better plan would be to build something akin to
> > Pyrex into the scheme of things, so that all the
> > refcount/GC issues are taken care of automatically.
>
> That sounds exciting. I have to adm
Christopher Armstrong <[EMAIL PROTECTED]> wrote:
> On 9/7/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > On 9/6/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > > > A better plan would be to bu
Fernando Perez <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > Here's a perspective "from the trenches" as it were.
> >
> > I've been writing quite a bit of code, initially all in Python (27k
> > lines in the last year or so). It worke
"Fredrik Lundh" <[EMAIL PROTECTED]> wrote:
>
> Karl Chen wrote:
>
> > Hi, has anybody considered adding something like this:
> > a = [1, 2]
> > [ 'x', *a, 'y']
> >
> > as syntactic sugar for
> > a = [1, 2]
> > [ 'x' ] + a + [ 'y' ].
> >
> > Notes:
> > - This is a common operation
Gareth McCaughan <[EMAIL PROTECTED]> wrote:
> The problems with syntax are
>
> 1 It adds cognitive load.
> 2 It makes your code look like line noise.
> 3 It reduces options for future development.
> 4 It complicates the parser.
>
> I don't know about #4, but I suspect it (along with the
Alexander,
The essence of what you have proposed has been proposed (multiple times) before,
and I seem to remember it was shot down.
The below functions offer the equivalent of list comprehensions with a
final post-processing step.
def cross(*args):
if len(args) == 1:
for i in args[
Alexander Myodov <[EMAIL PROTECTED]> wrote:
> Hello Josiah,
>
> JC> Alexander,
> JC> The essence of what you have proposed has been proposed (multiple times)
> before,
> JC> and I seem to remember it was shot down.
>
> To increase my understanding of Python-way, can you (or someone else)
> expl
Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
>
> > The best way to make people stop complaining about the GIL and start
> > using
> > process-based multiprogramming is to provide solid, standardized support
> > for process-based multiprogramming.
>
> 100% agreed. I needed a portable way to kno
Bill Janssen <[EMAIL PROTECTED]> wrote:
>
> > The best way to make people stop complaining about the GIL and start
> > using
> > process-based multiprogramming is to provide solid, standardized support
> > for process-based multiprogramming.
>
> And the model provided by the thread abstraction
Alexander Myodov <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Don't want to be importunate annoyingly asking the things probably
> trivial for experienced community, but need to ask it anyway, after
> spending about two hours trying to find well-camouflaged error caused
> by it.
In the future yo
"Andrew Koenig" <[EMAIL PROTECTED]> wrote:
>
>
> > My problem with this syntax is that it can be hard to read:
> >
> > return if self.arg is None then default else self.arg
> >
> > looks worryingly like
> >
> > return NAME NAME.NAME NAME NAME NAME NAME NAME NAME.NAME
> >
> > to me.
>
> Inte
Alexander Myodov <[EMAIL PROTECTED]> wrote:
[snip Alexander Myodov complaining about how Python works]
> i = 0
> while i != 1:
> i += 1
> j = 5
> print j
Maybe you don't realize this, but C's while also 'leaks' internal
variables...
int i = 0, j;
while (i != 1) {
i++;
j = 5;
}
p
Alexander Myodov <[EMAIL PROTECTED]> wrote:
> >> "for (int i = 0; i < 10; i++)" works fine nowadays.
> JC> I'm sorry, but you are wrong. The C99 spec states that you must define
> JC> the type of i before using it in the loop. Maybe you are thinking of
> JC> C++, which allows such things.
> "gc
Gareth McCaughan <[EMAIL PROTECTED]> wrote:
[seems to have gone off list with a portion of the discussion]
> > The reason I like "a if b else c" is because it has the
> > most natural word order. In English,
> >My dog is happy if he has a bone, else sad.
> > sounds much more natural than
> >
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
> At 03:35 PM 9/26/2005 -0700, Micah Elliott wrote:
> >Please read/comment/vote. This circulated as a pre-PEP proposal
> >submitted to c.l.py on August 10, but has changed quite a bit since
> >then. I'm reposting this since it is now "Open (under consi
Micah Elliott <[EMAIL PROTECTED]> wrote:
> Josiah> an unofficial spec is sufficient. See koders.com and search
> Josiah> for 'fixme' to see some common variants.
>
> But that's the problem -- there are already a bunch of "unofficial"
> specs, which don't serve much purpose as such. It's a cool
Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
> Le lundi 03 octobre 2005 à 14:59 +0200, Fredrik Lundh a écrit :
> > Antoine Pitrou wrote:
> >
> > > A good rule of thumb is to convert to unicode everything that is
> > > semantically textual
> >
> > and isn't pure ASCII.
>
> How can you be sure th
Michael Sparks <[EMAIL PROTECTED]> wrote:
> What I'd be interested in, is hearing how our system doesn't match with
> the goals of the hypothetical concurrency system you'd like to see (if it
> doesn't). The main reason I'm interested in hearing this, is because the
> goals you listed are ones we
Michael Sparks <[EMAIL PROTECTED]> wrote:
>
> On Thursday 06 October 2005 23:15, Josiah Carlson wrote:
> [... 6 specific use cases ...]
> > If Kamaelia is able to handle all of the above mechanisms in both a
> > blocking and non-blocking fashion, then I w
Adam Olsen <[EMAIL PROTECTED]> wrote:
> I need to stress that *only* the new, immutable and "thread-safe
> mark-and-sweep" types would be affected by these changes. Everything
> else would continue to exist as it did before, and the benchmark
> exists to show they can coexist without killing perf
Michael Sparks <[EMAIL PROTECTED]> wrote:
> [ Possibly overlengthy reply. However given a multiple sets of cans of
> worms... ]
> On Friday 07 October 2005 07:25, Josiah Carlson wrote:
> > One thing I notice is absent from the Kamaelia page is benchmarks.
>
> Th
Adam Olsen <[EMAIL PROTECTED]> wrote:
> On 10/7/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > Adam Olsen <[EMAIL PROTECTED]> wrote:
> > > I need to stress that *only* the new, immutable and "thread-safe
> > > mark-and-sweep" types wou
Michael Sparks <[EMAIL PROTECTED]> wrote:
> On Saturday 08 October 2005 04:05, Josiah Carlson wrote:
> > I'm just offering the above as example benchmarks (you certainly don't
> > need to do them to satisfy me, but I'll be doing those when my tuple
> > sp
Bruce Eckel <[EMAIL PROTECTED]> wrote:
>
> > I can (but won't) point out examples for days of bad decisions made for
> > the sake of speed, or policy that has been ignored for the sake of speed
> > (some of these overlap and some don't).
>
> As long as you've entered premature-optimization land,
Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Optionally, the existing "put" and "get" methods could be deprecated, with
> > the
> > goal of eventually changing their signature to match the put_wait and
> > get_wait
> > methods above.
>
> Apart from trying to guess the API without reading the
"Robert Brewer" <[EMAIL PROTECTED]> wrote:
> "Somewhat alleviated" and somewhat worsened. I've had half a dozen
> conversations in the last year about sharing data between threads; in
> every case, I've had to work quite hard to convince the other person
> that threading.local is *not* magic pixie
[Guido]
> >> Apart from trying to guess the API without reading the docs (:-), what
> >> are the use cases for using put/get with a timeout? I have a feeling
> >> it's not that common.
[Josiah Carlson]
> > With timeout=0, a shared connection/resource pool (
Eyal Lotem <[EMAIL PROTECTED]> wrote:
> Why not lazily import modules by importing them when they are needed
> (i.e inside functions), and not in the top-level module scope?
Because then it wouldn't be automatic.
The earlier portion of this discussion came from...
import module
#module.
Sokolov Yura <[EMAIL PROTECTED]> wrote:
>
> Offtopic:
>
> Microsoft Windows [Version 5.2.3790]
> (C) Copyright 1985-2003 Microsoft Corp.
>
> G:\Working\1>c:\Python24\python
> Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on
> win32
> Type "help", "copyright", "credits"
Technical Support of Intercable Co <[EMAIL PROTECTED]> wrote:
>
> And why not
> if len(sys.argv) > 1 take sys.argv[1] == 'debug':
> ...
>
> It was not so bad :-)
>
> A = len(sys.argv)==0 take None or sys.argv[1]
>
> Sorry for being noisy :-)
The syntax for 2.5 has already been decided upo
Calvin Spealman <[EMAIL PROTECTED]> wrote:
>
> On 10/11/05, Eyal Lotem <[EMAIL PROTECTED]> wrote:
> > locals()['x'] = 1 # Quietly fails!
> > Replaced by:
> > frame.x = 1 # Raises error
>
> What about the possibility of making this hypothetic frame object an
> indexable, such that fra
Calvin Spealman <[EMAIL PROTECTED]> wrote:
>
> On 10/14/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> >
> > Calvin Spealman <[EMAIL PROTECTED]> wrote:
> > >
> > > On 10/11/05, Eyal Lotem <[EMAIL PROTECTED]> wrote:
> >
Aahz <[EMAIL PROTECTED]> wrote:
>
> On Mon, Oct 17, 2005, Guido van Rossum wrote:
> >
> > If an argument is a string, it should be a method name, and the method
> > is looked up by that name each time the property is used. Because this
> > is late binding, it can be put before the method definiti
Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
> Jim Jewett wrote:
> > That said, I'm not sure the benefit is enough to justify the
> > extra complications, and your suggestion of allowing strings
> > for method names may be close enough. I agree that the
> > use of strings is awkward, but ... probab
Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
>
> > What would this mythical block statement look like that would make
> > properties easier to write than the above late-binding or the subclass
> > Property recipe?
>
> I suppose something like:
>
> class C(object):
> x = prop:
>
JanC <[EMAIL PROTECTED]> wrote:
>
> On 10/14/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > Until Microsoft adds kernel support for fork, don't expect standard
> > Windows Python to support it.
>
> AFAIK the NT kernel has support for fork, but the
Jim Jewett <[EMAIL PROTECTED]> wrote:
>
> (In http://mail.python.org/pipermail/python-dev/2005-October/057251.html)
> Eyal Lotem wrote:
>
> > Name: Attribute access for all namespaces ...
>
> > global x ; x = 1
> > Replaced by:
> > module.x = 1
>
> Attribute access as an option wou
Calvin Spealman <[EMAIL PROTECTED]> wrote:
> On 10/16/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
[snip]
> > What I'm saying is that whether or not you can modify the contents of
> > stack frames via tricks, you shouldn't. Why? Because as I said, if th
[EMAIL PROTECTED] wrote:
>
> > "Phillip" == Phillip J Eby <[EMAIL PROTECTED]> writes:
>
> Phillip> At 11:43 AM 10/19/2005 -0500, [EMAIL PROTECTED] wrote:
> >> >> :
> >> >>
> >> ...
> >>
> Steve> Wow, that's really neat. And you save a keyword! ;-)
> >>
>
Jim Jewett <[EMAIL PROTECTED]> wrote:
> (In http://mail.python.org/pipermail/python-dev/2005-October/057409.html,)
> Nick Coghlan suggested allowing attribute references as binding targets.
>
> >x = property("Property x (must be less than 5)")
>
> >def x.get(instance): ...
>
> Josiah s
Michel Pelletier <[EMAIL PROTECTED]> wrote:
>
> Martin Blais wrote:
> > Hi
> >
> > Just wondering, would anyone think of it as a good idea if the
> > enumerate() builtin could accept a "start" argument? I've run across
> > a few cases where this would have been useful. It seems generic
> > eno
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
> For efficiency's sake, however, CPython could simply store the
> execution context dictionary in its "thread state" structure, creating
> an empty dictionary at thread initialization time. This would make it
> somewhat easier to offer a C API for acce
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
> It's the responsibility of a coroutine scheduler to take a snapshot() when
> a task is suspended, and to swap() it in when resumed. So it doesn't
> matter that you've changed what thread you're running in, as long as you
> keep the context with the
r a __dict__ is that you don't
> > know what keys are available; meeting this use case with
> > attribute access would require some extra machinery, such as
> > an iterator over attributes.
>
> Josiah Carlson responded
> (http://mail.python.org/pipermail/python-dev/20
Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
> Reinhold Birkenfeld wrote:
> > Michele Simionato wrote:
> >> As other explained, the syntax would not work for functions (and it is
> >> not intended to).
> >> A possible use case I had in mind is to define inlined modules to be
> >> used as bunches
> >
Barry Warsaw <[EMAIL PROTECTED]> wrote:
> I've had this PEP laying around for quite a few months. It was inspired
> by some code we'd written which wanted to be able to get immutable
> versions of arbitrary objects. I've finally finished the PEP, uploaded
> a sample patch (albeit a bit incomplet
Michele Simionato <[EMAIL PROTECTED]> wrote:
>
> On 10/23/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > Very nice indeed. I'd be more supportive if it was defined as a new
> > statement
> > such as "create" with the syntax:
> >
> >create TYPE NAME(ARGS):
> > BLOCK
>
> I like it, but
Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> > You can get the same semantics with...
> >
> > class NAME(_(TYPE), ARGS):
> > BLOCK
> >
> > And a suitably defined _. Remember, not every X line function should be
> &g
Christopher Armstrong <[EMAIL PROTECTED]> wrote:
>
> On 10/24/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > "Should dicts and sets automatically freeze their mutable keys?"
> >
> > Dictionaries don't have mutable keys,
>
> Since wh
Nick Coghlan <[EMAIL PROTECTED]> wrote:
> I think having dicts and sets automatically invoke freeze would be a mistake,
> because at least one of the following two cases would behave unexpectedly:
I'm pretty sure that the PEP was only aslomg if one would freeze the
contents of dicts IF the dict
Michele Simionato <[EMAIL PROTECTED]> wrote:
>
> On 10/24/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > I would criticise it for being dangerously close to worthless. With the
> > minor support code that I (and others) have offered, no new syntax is
> >
Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> > Nick Coghlan <[EMAIL PROTECTED]> wrote:
> >> I think having dicts and sets automatically invoke freeze would be a
> >> mistake,
> >> because at least one of the followin
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> Fredrik Lundh wrote:
> > however, for Python 3000, it would be nice if the source-code encoding
> > applied
> > to the *entire* file (XML-style), rather than just unicode string literals
> > and (hope-
> > fully) comments and docstrings.
>
> As
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> > It seems that removing this restriction may cause serious issues, at
> > least in the case when using cyrillic characters in names. See recent
> > security issues in regards
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> > And how users could say, "name error? But I typed in window.draw(PEN) as
> > I was told to, and it didn't work!"
>
> Ah, so the "serious issues" you a
Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On 10/25/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > Indeed, they are similar, but_ different_ in my font as well. The trick
> > is that the glyphs are not different in the case of certain greek or
> >
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> M.-A. Lemburg wrote:
> > You even argued against having non-ASCII identifiers:
> >
> > http://mail.python.org/pipermail/python-list/2002-May/102936.html
> >
> > Do you really think that it will help with code readability
> > if programmers are al
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> > In this case it's not just a misreading, the characters look identical!
> > When is an 'E' not an 'E'? When it is an Epsilon or Ie. Saying what
> &g
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > According to wikipedia (http://en.wikipedia.org/wiki/Latin_alphabet),
> > various languages have adopted a transliteration of their language
> > and/or former alphabets into latin. They
Noam Raphael <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> I have thought about freezing for some time, and I think that it is a
> fundamental need - the need to know, sometimes, that objects aren't
> going to change.
I agree with this point.
> This is mostly the need of containers. dicts need to
Noam Raphael <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> It seems that we both agree that freezing is cool (-; . We disagree on
> whether a copy-on-write behaviour is desired. Your arguments agains
> copy-on-write are:
> 1. It's not needed.
> 2. It's complicated to implement.
>
> But first of all
Steve Holden <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> [...]
> >>Perhaps I didn't make it clear. The difference between wxPython's Grid
> >>and my table is that in the table, most values are *computed*. This
> >>means that ther
Noam Raphael <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I have slept quite well, and talked about it with a few people, and I
> still think I'm right.
And I'm going to point out why you are wrong.
> About the users-changing-my-internal-data issue:
>
> > Again, user semantics. Tell your users not
401 - 500 of 548 matches
Mail list logo
