"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> M.-A. Lemburg wrote:
> > Just because some codecs don't fit into the string.decode()
> > or bytes.encode() scenario doesn't mean that these codecs are
> > useless or that the methods should be banned.
>
> No. The reason to ban string.decode and bytes
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> > How are users confused?
>
> Users do
>
> py> "Martin v. Löwis".encode("utf-8")
> Traceback (most recent call last):
> File "", line 1,
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Stephen J. Turnbull wrote:
> >>"Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
>
> > Guido> - b = bytes(t, enc); t = text(b, enc)
> >
> > +1 The coding conversion operation has always felt like a constructor
> > to me, and in this parti
Bob Ippolito <[EMAIL PROTECTED]> wrote:
>
>
> On Feb 17, 2006, at 8:33 PM, Josiah Carlson wrote:
>
> >
> > Greg Ewing <[EMAIL PROTECTED]> wrote:
> >>
> >> Stephen J. Turnbull wrote:
> >>>>>>>> "Guido" =
Ron Adam <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > Bengt Richter had a good idea with bytes.recode() for strictly bytes
> > transformations (and the equivalent for text), though it is ambiguous as
> > to the direction; are we encoding or decoding with
Ron Adam <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
[snip]
> > Again, the problem is ambiguity; what does bytes.recode(something) mean?
> > Are we encoding _to_ something, or are we decoding _from_ something?
>
> This was just an example of one way that
Ron Adam <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > Ron Adam <[EMAIL PROTECTED]> wrote:
> >> Josiah Carlson wrote:
> > [snip]
> >>> Again, the problem is ambiguity; what does bytes.recode(something) mean?
> >>> Are we
Greg Ewing <[EMAIL PROTECTED]> wrote:
> Bengt Richter wrote:
>
> > My guess is that realistically default_factory will be used
> > to make clean code for filling a dict, and then turning the factory
> > off if it's to be passed into unknown contexts.
>
> This suggests that maybe the autodict beh
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote:
> [Martin v. Löwis]
> > This kind of invariant doesn't take into account
> > that there might be a default value.
>
> Precisely. Therefore, a defaultdict subclass violates the Liskov
> Substitution
> Principle.
class defaultdict(dict):
def __g
"Michael Urman" <[EMAIL PROTECTED]> wrote:
>
> On 2/19/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > My post probably hasn't convinced you, but much of the confusion, I
> > believe, is based on Martin's original belief that 'k in dd
"Stephen J. Turnbull" <[EMAIL PROTECTED]> wrote:
>
> >>>>> "Josiah" == Josiah Carlson <[EMAIL PROTECTED]> writes:
>
> Josiah> The question remains: is str.decode() returning a string
> Josiah> or unicode depending on
"Adam Olsen" <[EMAIL PROTECTED]> wrote:
> Can you say, for the record (since nobody else seems to care), if
> d.getorset(key, func) would work in your use cases?
It doesn't work for the multiset/accumulation case:
dd[key] += 1
- Josiah
___
Pytho
Michael Foord <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
> > Any build process would do. I would prefer to see the official tools on
> > the buildbot (i.e. VS.NET 2003),
I can get a free academic license for VS.NET 2003 professional with my
university (MSDNAA), and I've also got a Windo
"Adam Olsen" <[EMAIL PROTECTED]> wrote:
> However, I'm beginning to think we shouldn't be comparing them.
> defaultdict is a powerful but heavyweight option, intended for
> complicated behavior.
Check out Guido's patch. It's not that "heavyweight", and its intended
behavior is to make some opera
"Almann T. Goo" <[EMAIL PROTECTED]> wrote:
> I would like the community's opinion if there is enough out there that think
> this would be a worthwile endevour--or if there is already an initiative
> that I missed. Please let me know your questions, comments.
-1
Mechanisms which rely on manipula
"Almann T. Goo" <[EMAIL PROTECTED]> wrote:
> > Mechanisms which rely on manipulating variables within closures or
> > nested scopes to function properly can be elegant, but I've not yet seen
> > one that *really* is.
>
> This really isn't a case for or against what I'm proposing since we
> can al
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Stephen J. Turnbull wrote:
>
> > What I advocate for Python is to require that the standard base64
> > codec be defined only on bytes, and always produce bytes.
>
> I don't understand that. It seems quite clear to me that
> base64 encoding (in the gener
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
>
> > Mechanisms which rely on manipulating variables within closures or
> > nested scopes to function properly can be elegant, but I've not yet seen
> > one that *really* is.
>
> It see
"Steven Bethard" <[EMAIL PROTECTED]> wrote:
>
> On 2/21/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > The question which still remains in my mind, which I previously asked,
> > is whether the use cases are compelling enough to warrant the feature
&
Greg Ewing <[EMAIL PROTECTED]> wrote:
>u = unicode(b)
>u = unicode(b, 'utf8')
>b = bytes['utf8'](u)
>u = unicode['base64'](b) # encoding
>b = bytes(u, 'base64') # decoding
>u2 = unicode['piglatin'](u1) # encoding
>u1 = unicode(u2, 'piglatin') # decoding
Your
Just van Rossum <[EMAIL PROTECTED]> wrote:
>
> Ron Adam wrote:
>
> > Josiah Carlson wrote:
> > > Greg Ewing <[EMAIL PROTECTED]> wrote:
> > >>u = unicode(b)
> > >>u = unicode(b, 'utf8')
> > >>b = byte
It took me a while to get it set up, but we've got another Windows XP
buildbot slave running.
- Josiah
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/op
Josiah Carlson <[EMAIL PROTECTED]> wrote:
> It took me a while to get it set up, but we've got another Windows XP
> buildbot slave running.
Spoke too soon, not quite ready yet.
- Josiah
___
Python-Dev mailing list
Python-De
Georg Brandl <[EMAIL PROTECTED]> wrote:
> or something like
>
> m = re.match(...)
> if m.group(1) as filename:
> do something with filename
Except that m could be None, which would raise an exception during the
.group(1) call. Perhaps you meant...
m = re.match(...)
if m and m.group(1) as f
Ian Bicking <[EMAIL PROTECTED]> wrote:
>
> Neil Schemenauer wrote:
> >>Bad idea, as several pointed out -- quit() should return a 0 exit
> >>to the shell.
> >
> >
> > I like the idea of making "quit" callable. One small concern I have
> > is that people will use it in scripts to exit (rather t
Steven Elliott <[EMAIL PROTECTED]> wrote:
> I'm interested in how builtins could be more efficient. I've read over
> some of the PEPs having to do with making global variables more
> efficient (search for "global"):
> http://www.python.org/doc/essays/pepparade.html
> But I think the problem c
Samuele Pedroni <[EMAIL PROTECTED]> wrote:
>
> Raymond Hettinger wrote:
>
> > [Samuele Pedroni]
> >
> >> there's no sys.checkinterval in Jython. Implementing this would need the
> >> introduction of some kind of GIL implementation in Jython, the JVM
> >> has no primitive for global critical sec
"Christos Georgiou" <[EMAIL PROTECTED]> wrote:
> Well, what's the result of
>
> bytes([1,0,0])^ bytes([1,0])
>
> ? Is it bytes([0,0,0]) (à la little-endian) or is it bytes([1,1,0])
> (straight conversion to base-256)? Or perhaps throw a ValueError if the
> sizes differ?
It's a ValueError. I
Baptiste Carvello <[EMAIL PROTECTED]> wrote:
> Josiah Carlson a écrit :
>
> > They aren't considered because they are *obvious* to most (if not all)
> > sane people who use Python.
>
> They are not *that* obvious. Logical operations on ints have allowed
"Christos Georgiou" <[EMAIL PROTECTED]> wrote:
> [Christos]
> > These details should be considered in the PEP.
>
> [Josiah]
> > They aren't considered because they are *obvious* to most (if not all)
> > sane people who use Python.
>
> I beg to disagree. I don't know whether you are Dutch or not
"Brett Cannon" <[EMAIL PROTECTED]> wrote:
>
> With the discussion of a possible @decorator to help set the metadata
> of the decorator to that of what the wrapped function has, I had an
> idea that I wanted to toss out there (this dicussion stems from a blog
> post I made:
> http://sayspy.blogsp
"Neal Norwitz" <[EMAIL PROTECTED]> wrote:
>
> I posted a message to c.l.p about the upcoming alpha 1.
>
> Just in case anybody here's been snoozing, 2.5 alpha 1 is coming up
> real quick, hopefully within a couple of weeks. If you have any
> *major* features (particularly implemented in C) that
Michael Chermside <[EMAIL PROTECTED]> wrote:
>
> Barry writes:
> > I still believe in this, and I'm thankful for the support I've seen. It
> > won't happen for Python 2.x, but I do plan on addressing this for Py3K.
>
> When you do, I'd like you to consider one change to the names. You are
> pro
Anthony Baxter <[EMAIL PROTECTED]> wrote:
> This came up before (back in October 2004!) but didn't go anywhere
> since, AFAICR. Do we want to consider including pysqlite in Python
> 2.5? It's the only DB adaptor that I'd really consider suitable for
> shipping with the distribution, because it'
Anthony Baxter <[EMAIL PROTECTED]> wrote:
>
> On Tuesday 28 March 2006 19:13, Giovanni Bajo wrote:
> > Another option would be Bugzilla, which is proven to be stable,
> > maintained and used succesfully by large open source projects (like
> > GCC+RedHat+Binutils+Classpath).
>
> Please god no. No
Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Tue, 2006-03-28 at 18:24 -0500, Phillip J. Eby wrote:
>
> > On the plus side, it sounds like ASPW is a more general wrapping of SQLite,
> > which seems to me to lean in its favor for the stdlib, if it can also be
> > brought into DBAPI compliance.
>
Neal Becker <[EMAIL PROTECTED]> wrote:
>
> I'd like to start several processes, each a pipe reading from my python main
> process. It looks like I want to write all my data to each process, then
> use communicate(), but I don't want to wait for each process yet, since
> then they would block eac
"tomer filiba" <[EMAIL PROTECTED]> wrote:
> isn't the latter more elegant?
According to my experience with Python, as well as my interpretations of
the zens, no. -1
> and the zen supports my point:
> (*) Beautiful is better than ugly --> f(*(args + (7,))) is ugly
But explicit is better than imp
Greg Ewing <[EMAIL PROTECTED]> wrote:
> 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
"tomer filiba" <[EMAIL PROTECTED]> wrote:
> the evaluated string will be evaluated based on the current scope (locals
> and globals), just like
> normal expressions. the difference is, the results of the expressions will
> be str()ed into the
> evaluated string directly. these expressions will be
Dennis Heuer <[EMAIL PROTECTED]> wrote:
> I often experiment with touring machine algorithms and play around with
> alternative arithmetics. I'd like to do that with python but it offers
> only the standard bitwise operators. They're fine if one wants to do
> manipulations on the full integer. How
"Tim Peters" <[EMAIL PROTECTED]> wrote:
> [Mateusz Rukowicz]
> >> And last thing - It would be nice to add some number-theory functions to
> >> math module (or new one), like prime-tests,
>
> If they think doing much more here is out of bounds for them, trying
> to sneak it into longobject.c is c
There exists various C and Python implementations of both AVL and
Red-Black trees. For users of Python who want to use AVL and/or
Red-Black trees, I would urge them to use the Python implementations.
In the case of *needing* the speed of a C extension, there already
exists a CPython extension mo
"tomer filiba" <[EMAIL PROTECTED]> wrote:
> "[" for in [if ] [except
> : ] "]"
Note that of the continue cases you offer, all of them are merely simple
if condition (though the file example could use a better test than
os.path.isfile).
[x for x in a if x.startswith("y") except AttributeEr
"Vladimir 'Yu' Stepanov" <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > There exists various C and Python implementations of both AVL and
> > Red-Black trees. For users of Python who want to use AVL and/or
> > Red-Black trees, I would urge
"tomer filiba" <[EMAIL PROTECTED]> wrote:
> first, i posted it two days ago, so it's funny it got posted only now...
> the moderators are sleeping on the job :)
I don't believe python-dev has moderators...or at least my posts have
never been delayed like that.
> > Note that of the continue case
Dennis Heuer <[EMAIL PROTECTED]> wrote:
>
> OK, let's get back to the bitarray type. To first be clear about the
> *type* of bitarray: The type I talk about is really a *bit*-array and
> not a *bytewise*-array, as most developers seem to think of it. The
> array doesn't provide the boolean manipu
I understand the underlying implementation of str.join can be a bit
convoluted (with the auto-promotion to unicode and all), but I don't
suppose there is any chance to get str.join to support objects which
implement the buffer interface as one of the items in the sequence?
Something like:
Edward Loper <[EMAIL PROTECTED]> wrote:
>
> Nick Coghlan wrote:
> > Edward Loper wrote:
> >> This is incompatible with the recent proposal making str.join
> >> automatically str-ify its arguments. i.e.:
> >>
> >>''.join(['a', 12, 'b']) -> 'a12b'.
> >>
> >> I don't feel strongly about either
Thomas Heller <[EMAIL PROTECTED]> wrote:
>
> Fredrik Lundh wrote:
> > Josiah Carlson wrote:
> >
> >> At least for the examples of buffers that I've seen, using the buffer
> >> interface for objects that support it is equivalent to automatically
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> On 4/29/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > I understand the underlying implementation of str.join can be a bit
> > convoluted (with the auto-promotion to unicode and all), but I don't
> >
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > Specifically in the case of bytes.join(), the current common use-case of
> > .join(...) would become something similar to
> > bytes().join(...), unless bytes objects got a syntax... Or
&g
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> >> I think what you are missing is that algorithms that currently operate
> >> on byte strings should be reformulated to operate on character strings,
> >> not refo
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> >> I mean unicode strings, period. I can't imagine what "unicode strings
> >> which do not contain data" could be.
> >
> > Binary data as opposed to text.
ce that with 'operationX'. I will do that in all of my further
replies.
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > Certainly that is the case. But how would you propose embedded bytes
> > data be represented? (I talk more exte
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> >>> Certainly that is the case. But how would you propose embedded bytes
> >>> data be represented? (I talk more extensively about this particular
> >>> issue la
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> This discussion seems to have gotten a bit out of hand. I believe it
> belongs on the python-3000 list.
I accidentally jumped the gun on hitting 'send' on my most recent reply,
I'll repost it in the Py3k list and expect further discussion to proceed
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> 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.
for line in lines:
"Vladimir 'Yu' Stepanov" <[EMAIL PROTECTED]> wrote:
> Comparison of functions of sorting and binary trees not absolutely
> correctly. I think that function sort will lose considerably on
> greater lists. Especially after an insert or removal of all one element.
Generally speaking, people who un
"Vladimir 'Yu' Stepanov" <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > However, as I just said, people usually don't remove items from
> > just-sorted lists, they tend to iterate over them via 'for i in list:' .
> >
> S
Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
>
> On Fri, 5 May 2006 08:20:02 -0500, Michael Urman <[EMAIL PROTECTED]> wrote:
> >On 5/5/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
> >> At present, Python allows this as a choice.
> >
> >Not always - take a look from another perspective:
> >
> >def
"Vladimir 'Yu' Stepanov" <[EMAIL PROTECTED]> wrote:
>
> Martin v. Löwis wrote:
> > Vladimir 'Yu' Stepanov wrote:
> >
> >> Yes. I understood it when resulted a set example.
> >>
> >>> However, as I just said, people usually don't remove items from
> >>> just-sorted lists, they tend to iter
"Vladimir 'Yu' Stepanov" <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > This problem has nothing to do with dictionaries and hashing, it has to
> > do with the fact that there may not be a total ordering on the elements
> > of a sequence.
&
Heiko Wundram <[EMAIL PROTECTED]> wrote:
>
> Am Sonntag 21 Mai 2006 22:11 schrieb Talin:
> > As a general guideline, I've noticed that proposals which are purely
> > syntactic sugar are unlikely to be accepted unless there is some
> > additional benefit other than just compression of source code.
Niko Matsakis <[EMAIL PROTECTED]> wrote:
>
> > I saw them. Your brain must be wired very differently
> > to mine, because I find loops with a continue in them
> > harder to follow than ones without -- exactly the
> > opposite of what you seem to prefer.
>
> Delurking for no particular reason:
>
Heiko Wundram <[EMAIL PROTECTED]> wrote:
> Why isn't this good practice? It's not always sensible to refactor loop code
> to call methods (to make the loop body shorter), and it's a pretty general
> case that you only want to iterate over part of a generator, not over the
> whole content. Becau
Bob Ippolito <[EMAIL PROTECTED]> wrote:
> One problem with buffer() is that it does a memcpy of the buffer. A
> zero-copy version of buffer (a view on some object that implements
> the buffer API) would be nice.
Did buffers change? I seem to remember that there were segfaulting
conditions wh
"Thomas Wouters" <[EMAIL PROTECTED]> wrote:
> On 5/29/06, Bob Ippolito <[EMAIL PROTECTED]> wrote:
> >
> > A compromise is to do proper range checking as a warning, and do the
> > modulo math anyway... but is that what we really want?
> >
>
> I don't know about the rest of 'us', but that's what I
"Fredrik Lundh" <[EMAIL PROTECTED]> wrote:
> Tim Peters wrote:
>
> "abc".count("", 100)
> > 1
> u"abc".count("", 100)
> > 1
>
> which is the same as
>
> >>> "abc"[100:].count("")
> 1
>
> "abc".find("", 100)
> > 100
> u"abc".find("", 100)
> > 100
> >
> > today, although the
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Tim Peters wrote:
>
> > I liked benchmarking on Crays in the good old days. ...
> > Test times were reproducible to the
> > nanosecond with no effort. Running on a modern box for a few
> > microseconds at a time is a way to approximate that, provide
Alex Martelli <[EMAIL PROTECTED]> wrote:
>
> ...claims:
>
> Note that for even rather small len(x), the total number of
> permutations of x is larger than the period of most random number
> generators; this implies that "most" permutations of a long
> sequence can never be generated.
[snip]
> I
Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> Alex Martelli <[EMAIL PROTECTED]> wrote:
> >
> > ...claims:
> >
> > Note that for even rather small len(x), the total number of
> > permutations of x is larger than the period of most rando
[EMAIL PROTECTED] wrote:
>
>
> Greg> Before accepting this, we could do with some debate about the
> Greg> syntax. It's not a priori clear that C-style switch/case is the
> Greg> best thing to adopt.
>
> Oh sure. That debate should probably leverage PEP 275.
Along the lines of PEP
Boris Borcic <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Armin Rigo wrote:
> > Hi,
> >
> > On Wed, Jun 07, 2006 at 02:07:48AM +0200, Thomas Wouters wrote:
> >> I just submitted http://python.org/sf/1501934 and assigned it to Neal so it
> >> doesn't get forgotten before 2.5 goes out ;) It seems Pytho
ssignment and
nested scopes is proper and sufficient. Believe whatever you want about
my intentions.
> Josiah Carlson wrote:
> > and significantly more readable if it were implemented as a
> > class.
>
> I'll deny that flatly since first of all the issue isn't
Boris Borcic <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
>
> > You seem to not realize that these different use-cases. Your new
> > example involves a global variable that is *shared* among everyone that
> > knows about this particular module. I
Boris Borcic <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
>
> > The closure/class example is merely a method of encapsulating state,
> > which I find easier to define, describe, and document than the closure
> > version.
>
> In the case of the co
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
> At 11:26 AM 6/14/2006 -0700, Josiah Carlson wrote:
> >Ok, so here's a bit of a benchmark for you.
> >
> > def helper(x,y):
> > return y
> >
> > def fcn1(x):
> >
As Guido has already asked for this thread to be moved to c.l.py, I'm
going to do so.
- Josiah
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/py
"Noam Raphael" <[EMAIL PROTECTED]> wrote:
>
> 2006/6/16, Gareth McCaughan <[EMAIL PROTECTED]>:
> > None of the above is intended to constitute argument for
> > or against Noam's proposed change to Python. Python isn't
> > primarily a language for mathematicians, and so much the
> > better for Pyt
There is a related bit of functionality for subprocess that would allow
for asynchronous handling of IO to/from the called subprocess. It has
been implemented as a recipe [1], but requires the use of additional
pywin32 functionality on Windows. As was the case for the original
subprocess module,
Thomas Lee <[EMAIL PROTECTED]> wrote:
> I see. But restricting the switch to constants in the name of
> performance may not make sense in a language like Python. Maybe this is
> something for the PEP to discuss, but it seems such an implementation
> would be confusing and sometimes it may not be p
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
> At 06:56 PM 6/18/2006 -0700, Josiah Carlson wrote:
> >The non-fast version couldn't actually work if it referenced any names,
> >given current Python semantics for arbitrary name binding replacements.
>
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> Perhaps I misunderstood Josiah's comment; I thought he was implying
> that a switch should be significantly *faster* than if/elif, and was
> arguing against features that would jeopardize that speedup. I would
> think that it would be fine if some sw
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>
> On 6/19/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > Regardless of readability (I know that readability counts), TOOWTDI. If
> > we allow somewhat arbitrary cases, then any potential speedup may be
&
Anthony Baxter <[EMAIL PROTECTED]> wrote:
> 2.5b1 is out, so I'm declaring the SVN trunk unfrozen. Note, though,
> that as we're now post-beta, we're in FEATURE FREEZE.
Hey Raymond, any word on those binascii additions, or should I clean up
that struct patch and add in some tests?
- Josiah
_
Talin <[EMAIL PROTECTED]> wrote:
>
> I'm sure I am not the first person to say this, but how about:
>
> global x = 12
>
> (In other words, declare a global and assign a value to it - or another
> way of saying it is that the 'global' keyword acts as an assignment
> modifier.)
If we allow
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> (1) An expression of the form 'static' has the semantics of
> evaluating the atom at the same time as the nearest surrounding
> function definition. If there is no surrounding function definition,
> 'static' is a no-op and the expression is evaluate
"Alex Martelli" <[EMAIL PROTECTED]> wrote:
> On 6/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Independent from this, I wonder if we also need static names of the form
> >
> > static =
> >
> > which would be similar to
> >
> >= static ()
> >
> > but also prevents from being assi
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> On 6/23/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> > > Independent from this, I wonder if we also need static names of the form
> &
"Eric Sumner" <[EMAIL PROTECTED]> wrote:
>
> On 6/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > No; in order to make it possible to use a single dict lookup for
> > dispatch, the set members are expanded into the dict key. If you have
> > a large contiguous range, you'll be better off (s
Nick Maclaren <[EMAIL PROTECTED]> wrote:
> "Facundo Batista" <[EMAIL PROTECTED]> wrote:
> >
> > Well, so I'm completely lost... because, if all you want is to be able
> > to chose a returned value or an exception raised, you actually can
> > control that in Decimal.
>
> Yes, but I have so far fa
Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> On Fri, 23 Jun 2006, Josiah Carlson wrote:
> > This is a good thing, because if switch/case ends up functionally
> > identical to if/elif/else, then it has no purpose as a construct.
>
> This doesn't make sense as a rule.
Talin <[EMAIL PROTECTED]> wrote:
> My version of this is to add to Python the notion of a simple
> old-fashioned subroutine - that is, a function with no arguments and no
> additional scope, which can be referred to by name. For example:
I don't like the idea of an embedded subrutine for a few
Talin <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > Talin <[EMAIL PROTECTED]> wrote:
> >
> >>My version of this is to add to Python the notion of a simple
> >>old-fashioned subroutine - that is, a function with no arguments and no
> >
Gregor Lingl <[EMAIL PROTECTED]> wrote:
> Could you imagine - downgrading it's 'featureness' - to put it into 2.5.1
> or something like this?
Changing features/abilities of Python in micro releases (2.5 -> 2.5.1),
aside from bugfixes, is a no-no. See the Python 2.2 -> 2.2.1
availability of True/
"Alexander Belopolsky" <[EMAIL PROTECTED]> wrote:
> On 6/29/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> >... dict is more basic, set is just a special case of
> > dict for performance reasons. Also, dict is used to define and implement
> > the language itself, set is "just" a predefined typ
I've previously asked on python-list, but have recieved no responses or
explanations. Maybe someone here with a better memory can help, and I
apologize for asking a somewhat off-topic question about such an archaic
version of Python.
According to my reading of Python 2.3 docs, the call to goo()
Nick Maclaren <[EMAIL PROTECTED]> wrote:
> "Tim Peters" <[EMAIL PROTECTED]> wrote:
>
> [ Many useful answers ]
>
> Thanks very much! That helps. Here are a few points where we are at
> cross-purposes.
[snip]
> I believe that, using the above approach, it would be possible to
> achieve good eff
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> > Any pointers as to why there is a difference would be appreciated.
>
> This was fixed in r35540, r35541, r35542, r35543, by Nick Bastin
> and Armin Rigo, in response to #765624
301 - 400 of 548 matches
Mail list logo
