On 2/20/06, Tim Peters <[EMAIL PROTECTED]> wrote:
>
> Speaking as a PSF director, I might not vote for that :-) Fact is
> I've been keeping the build & tests 100% healthy on WinXP Pro, and
> that requires more than just running the tests (it also requires
> repairing compiler warnings and Unixisms
On 2/20/06, Bengt Richter <[EMAIL PROTECTED]> wrote:
> Perhaps a more informative message would be nice.
> Here's an easy way to trigger it:
>
> >>> compile("#-*- coding: ascii -*-\nprint 'ab%c'\n"%0x80, '','exec')
> Traceback (most recent call last):
>File "", line 1, in ?
> MemoryError
Th
M.-A. Lemburg wrote:
> I'd say that the parties interested in non-Unicode versions of
> Python should maintain these branches of Python. Dito for other
> stripped down versions.
I understand where you're coming from but the embedded market I encounter
tends to focus on the hardware side. If the
On 21-feb-2006, at 9:09, Neal Norwitz wrote:
> Unfortunately, there are a ton of
> warnings on OS X right now.
How many of those do you see when you ignore the warnings you get
while building the Carbon extensions? Those extensions wrap loads of
deprecated functions, each of which will give a w
On 2/21/06, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
>
> On 21-feb-2006, at 9:09, Neal Norwitz wrote:
>
> > Unfortunately, there are a ton of
> > warnings on OS X right now.
>
> How many of those do you see when you ignore the warnings you get
> while building the Carbon extensions? Those extensi
On 21-feb-2006, at 10:19, Neal Norwitz wrote:
> On 2/21/06, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
>>
>> On 21-feb-2006, at 9:09, Neal Norwitz wrote:
>>
>>> Unfortunately, there are a ton of
>>> warnings on OS X right now.
>>
>> How many of those do you see when you ignore the warnings you ge
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>> Note that this does not mean that we should forget about memory
>> consumption issues. It's just that if there's only marginal
>> interest in certain special builds of Python, I don't see the
>> requirement for the Python core developers to maintain
Jeff Rush wrote:
> M.-A. Lemburg wrote:
>
>> I'd say that the parties interested in non-Unicode versions of
>> Python should maintain these branches of Python. Dito for other
>> stripped down versions.
>
> I understand where you're coming from but the embedded market I
> encounter tends to focus
Delaney, Timothy (Tim) wrote:
> However, *because* Python uses duck typing, I tend to feel that
> subclasses in Python *should* be drop-in replacements.
Duck-typing means that the only reliable way to
assess whether two types are sufficiently compatible
for some purpose is to consult the document
Ron Adam wrote:
> Storing byte information as 16 or 32 bits ints could take up a rather
> lot of memory in some cases.
I don't quite see the point here. Inside a bytes object,
they would be stored 1 byte per byte. Nobody is suggesting
that they would take up more than that just because
a_bytes_o
Ron Adam wrote:
> Storing byte information as 16 or 32 bits ints could take up a rather
> lot of memory in some cases.
I don't quite see the point here. Inside a bytes object,
they would be stored 1 byte per byte. Nobody is suggesting
that they would take up more than that just because
a_bytes_o
Guido van Rossum wrote:
> It's quite tricky to implement a fully
> transparent wrapper that supports all the special
> methods (__setitem__ etc.).
I was thinking the wrapper would only be a means of
filling the dict -- it wouldn't even pretend to
implement the full dict interface. The only metho
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 general sense of encoding, not the
unicode sense) takes binar
Bengt Richter wrote:
> you could write
>
> d = dict()**list
Or alternatively,
ld = dict[list]
i.e. "a dict of lists". In the maximally twisted
form of this idea, the result wouldn't be a dict
but a new *type* of dict, which you would then
instantiate:
d = ld(your_favourite_args_here
Josiah Carlson wrote:
> Introducing these two new keywords is equivalent to
> encouraging nested scope use. Right now nested scope
> use is "limited" or "fraught with gotchas".
What you seem to be saying here is: Nested scope use
is Inherently Bad. Therefore we will keep them Limited
and Fraugh
Greg Ewing wrote:
>Delaney, Timothy (Tim) wrote:
>
>
>
>>However, *because* Python uses duck typing, I tend to feel that
>>subclasses in Python *should* be drop-in replacements.
>>
>>
>
>Duck-typing means that the only reliable way to
>assess whether two types are sufficiently compatible
>fo
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 seems a bit inconsistent to say on the one hand
that direct assignment to a name in an outer scope
is no
Neal> IMO compiler warnings should generate emails from buildbot.
It doesn't generate emails for any other condition. I think it should just
turn the compilation section yellow.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.
>> Unfortunately, there are a ton of warnings on OS X right now.
Ronald> How many of those do you see when you ignore the warnings you
Ronald> get while building the Carbon extensions?
I see a bunch related to Py_ssize_t. Those have nothing to do with Carbon.
I don't see them on th
On Fri, 2006-02-17 at 00:43 -0500, Steve Holden wrote:
> Fredrik Lundh wrote:
> > Barry Warsaw wrote:
> >
> >
> >>We know at least there will never be a 2.10, so I think we still have
> >>time.
> >
> >
> > because there's no way to count to 10 if you only have one digit?
> >
> > we used to thi
On Sun, 2006-02-19 at 23:30 +0900, Stephen J. Turnbull wrote:
> > "M" == "M.-A. Lemburg" <[EMAIL PROTECTED]> writes:
> M> * for Unicode codecs the original form is Unicode, the derived
> M> form is, in most cases, a string
>
> First of all, that's Martin's point!
>
> Second, almost a
Almann,
The lack of support for rebinding names in enclosing scopes is
certainly a wart. I think option one is a better fit for Python,
because it more closely matches the existing naming semantics. Namely
that assignment in a block creates a new name unless a global
statement indicates otherwis
Jeremy,
I definitely agree that option one is more in line with the semantics
in place within Python today.
> The names of naming statements are quite hard to get right, I fear. I
> don't particularly like "use." It's too generic. (I don't
> particularly like "scope" for option 2, either, for
On 2/20/06, Bengt Richter <[EMAIL PROTECTED]> wrote:
> How about doing it as an expression, empowering ( ;-) the dict just afer
> creation?
> E.g., for
>
> d = dict()
> d.default_factory = list
>
> you could write
>
> d = dict()**list
Bengt, can you let your overactive imagination res
On 2/21/06, Fuzzyman <[EMAIL PROTECTED]> wrote:
> I've had problems in code that needs to treat strings, lists and
> dictionaries differently (assigning values to a container where all
> three need different handling) and telling the difference but allowing
> duck typing is *problematic*.
Consider
Ronald> How many of those do you see when you ignore the warnings you
Ronald> get while building the Carbon extensions?
skip> I see a bunch related to Py_ssize_t. Those have nothing to do
skip> with Carbon. I don't see them on the gentoo build, so I assume
skip> they just ha
On Tue, Feb 21, 2006 at 08:02:08AM -0500, Jeremy Hylton wrote:
> The lack of support for rebinding names in enclosing scopes is
> certainly a wart. I think option one is a better fit for Python,
> because it more closely matches the existing naming semantics. Namely
> that assignment in a block
On Tue, 21 Feb 2006 08:02:08 -0500, "Jeremy Hylton" <[EMAIL PROTECTED]> wrote:
>Almann,
>
>The lack of support for rebinding names in enclosing scopes is
>certainly a wart. I think option one is a better fit for Python,
>because it more closely matches the existing naming semantics. Namely
>that
I had to lookup top-post :-).
On 2/21/06, Bengt Richter <[EMAIL PROTECTED]> wrote:
> On Tue, 21 Feb 2006 08:02:08 -0500, "Jeremy Hylton" <[EMAIL PROTECTED]> wrote:
> >Jeremy
> Hey, only Guido is allowed to top-post. He said so ;-)
The Gmail UI makes it really easy to forget where the q
> But to
On 2/21/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> I had to lookup top-post :-).
>
> On 2/21/06, Bengt Richter <[EMAIL PROTECTED]> wrote:
> > On Tue, 21 Feb 2006 08:02:08 -0500, "Jeremy Hylton" <[EMAIL PROTECTED]>
> > wrote:
> > >Jeremy
> > Hey, only Guido is allowed to top-post. He said so ;-
> But to the topic, it just occurred to me that any outer scopes could be given
> names
> (including global namespace, but that would have the name global by default,
> so
> global.x would essentially mean what globals()['x'] means now, except it would
> be a name error if x didn't pre-exist when
Jeremy Hylton wrote:
> On 2/21/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
>> I had to lookup top-post :-).
>>
>> On 2/21/06, Bengt Richter <[EMAIL PROTECTED]> wrote:
>>> On Tue, 21 Feb 2006 08:02:08 -0500, "Jeremy Hylton" <[EMAIL PROTECTED]>
>>> wrote:
Jeremy
>>> Hey, only Guido is allowed
On Fri, 2006-02-17 at 14:01 +0100, Georg Brandl wrote:
> Fredrik Lundh wrote:
> > Georg Brandl wrote:
> >
> >> as Jim Jewett noted, multifile is supplanted by email as much as mimify
> >> etc.
> >> but it is not marked as deprecated. Should it be deprecated in 2.5?
> >
> > -0.5 (gratuitous break
On Feb 21, 2006, at 1:51 AM, Greg Ewing wrote:
...
> Just one more thing -- have you made a final decision
> about the name yet? I'd still prefer something like
> 'autodict', because to me 'defaultdict' suggests
autodict is shorter and sharper and I prefer it, too: +1
> etc.) it seems more a
Guido van Rossum wrote:
>On 2/21/06, Fuzzyman <[EMAIL PROTECTED]> wrote:
>
>
>>I've had problems in code that needs to treat strings, lists and
>>dictionaries differently (assigning values to a container where all
>>three need different handling) and telling the difference but allowing
>>duck ty
Greg Ewing wrote:
>def my_func():
> namespace foo
> foo.x = 42
>
> def inc_x():
>foo.x += 1
>
> The idea here is that foo wouldn't be an object in
> its own right, but just a collection of names that
> would be implemented as local variables of my_func.
But why is tha
> Why not just use a class?
>
>
> def incgen(start=0, inc=1) :
> class incrementer(object):
> a = start - inc
> def __call__(self):
> self.a += inc
> return self.a
> return incrementer()
>
> a = incgen(7, 5)
> for n in range(10):
> print a(),
Because I thi
M.-A. Lemburg wrote:
> Note that I'm not saying that these switches are useless - of
> course they do allow to strip down the Python interpreter.
> I believe that only very few people are interested in having these
> options and it's fair enough to put the burden of maintaining these
> branches on
"Neal Norwitz" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> There's nothing to prevent buildbot from making debug builds, though
> that is not currently done.
Now that there are separate report pages for 2.4 and 2.5, you could add
pages for debug builds, perhaps with a lower fr
On 2/21/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
>
> On Feb 21, 2006, at 1:51 AM, Greg Ewing wrote:
> ...
> > Just one more thing -- have you made a final decision
> > about the name yet? I'd still prefer something like
> > 'autodict', because to me 'defaultdict' suggests
>
> autodict is sh
Barry Warsaw wrote:
> On Fri, 2006-02-17 at 14:01 +0100, Georg Brandl wrote:
>> Fredrik Lundh wrote:
>> > Georg Brandl wrote:
>> >
>> >> as Jim Jewett noted, multifile is supplanted by email as much as mimify
>> >> etc.
>> >> but it is not marked as deprecated. Should it be deprecated in 2.5?
>>
On Tue, 21 Feb 2006 05:58:52 -0800, "Guido van Rossum" <[EMAIL PROTECTED]>
wrote:
>On 2/20/06, Bengt Richter <[EMAIL PROTECTED]> wrote:
>> How about doing it as an expression, empowering ( ;-) the dict just afer
>> creation?
>> E.g., for
>>
>> d = dict()
>> d.default_factory = list
>>
>>
Greg Ewing wrote:
> Ron Adam wrote:
>
>> Storing byte information as 16 or 32 bits ints could take up a rather
>> lot of memory in some cases.
>
> I don't quite see the point here. Inside a bytes object,
> they would be stored 1 byte per byte. Nobody is suggesting
> that they would take up more
On Tue, 2006-02-21 at 17:18 +0100, Georg Brandl wrote:
> > IIRC, when I brought this up ages ago, there was some grumbling that
> > multifile is useful for other than email/MIME applications. Still, I'm
> > +1 on PEP 4'ing it.
>
> Which means "go ahead" or "wait for others to be -1"?
s/or/and/
On Sat, 2006-02-18 at 14:44 +0100, M.-A. Lemburg wrote:
> In Py 2.5 we'll change that. The encodings package search
> function will only allow codecs in that package to be
> imported. All other codec packages will have to provide
> their own search function and register this with the
> codecs regi
Almann T. Goo <[EMAIL PROTECTED]> wrote:
>> 1. Adding a keyword such as "use" that would follow similar semantics as
"
>> global" does today. A nested scope could declare names with this keyword
>> to enable assignment to such names to change the closest parent's
binding.
+0, and I like "outer"
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
>> > Just one more thing -- have you made a final decision
>> > about the name yet? I'd still prefer something like
>> > 'autodict', because to me 'defaultdict' suggests
>>
>> autodict is shorter and sharper and I prefer it, too: +1
>
> Apart from it somehow hashing to the same place as "autodidact
"Almann T. Goo" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I certainly hope that an initiative like this doesn't get stymied by
> the lack of a good name for such a keyword. Maybe something like
> "outer"?
Adding a keyword has a cost that you have so far ignored. Guido is
On 2/21/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Almann T. Goo" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
> > I certainly hope that an initiative like this doesn't get stymied by
> > the lack of a good name for such a keyword. Maybe something like
> > "outer"?
>
> Addi
Barry Warsaw wrote:
> On Tue, 2006-02-21 at 17:18 +0100, Georg Brandl wrote:
>
>> > IIRC, when I brought this up ages ago, there was some grumbling that
>> > multifile is useful for other than email/MIME applications. Still, I'm
>> > +1 on PEP 4'ing it.
>>
>> Which means "go ahead" or "wait for
Then you will likely be happy with Guido's current version of the patch.
- Original Message -
From: "Crutcher Dunnavant" <[EMAIL PROTECTED]>
To: "Raymond Hettinger" <[EMAIL PROTECTED]>
Cc: "Python Dev"
Sent: Monday, February 20, 2006 8:57 PM
Subject: Re: [Python-Dev] defaultdict proposal
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 seems a bit inconsistent to say on the one hand
Hye-Shik Chang wrote:
> On 2/19/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> M.-A. Lemburg wrote:
>>> Walter Dörwald wrote:
Anyway, I've started implementing a patch that just adds
codecs.StatefulEncoder/codecs.StatefulDecoder. UTF8, UTF8-Sig,
UTF-16, UTF-16-LE and UTF-16-BE ar
Walter Dörwald wrote:
> Hye-Shik Chang wrote:
>
>> On 2/19/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>>> M.-A. Lemburg wrote:
Walter Dörwald wrote:
> Anyway, I've started implementing a patch that just adds
> codecs.StatefulEncoder/codecs.StatefulDecoder. UTF8, UTF8-Sig,
> UTF
At 11:31 AM 2/21/2006 -0800, Josiah Carlson wrote:
>Greg Ewing <[EMAIL PROTECTED]> wrote:
> >
> > It seems a bit inconsistent to say on the one hand
> > that direct assignment to a name in an outer scope
> > is not sufficiently useful to be worth supporting,
> > while at the same time providing a
With Neal Norwitz's help, I've submitted an initial patch to implement
the "with" statement from PEP 343 (SourceForge request ID 1435715).
There is a little more work to be done (on the doc especially), and I
have a couple of questions written up on the SourceForge page, but the
code works to the
On 21 Feb 2006, at 19:25, Jeremy Hylton wrote:
> If I recall the discussion correctly, Guido said he was open to a
> version of nested scopes that allowed rebinding.
PEP 227 mentions using := as a rebinding operator, but rejects the
idea as it would encourage the use of closures. But to me it s
Mark Russell wrote:
> PEP 227 mentions using := as a rebinding operator, but rejects the
> idea as it would encourage the use of closures. But to me it seems
> more elegant than some special keyword, especially is it could also
> replace the "global" keyword. It doesn't handle things like
Mark Russell wrote:
> On 21 Feb 2006, at 19:25, Jeremy Hylton wrote:
>
>>If I recall the discussion correctly, Guido said he was open to a
>>version of nested scopes that allowed rebinding.
>
>
> PEP 227 mentions using := as a rebinding operator, but rejects the
> idea as it would encourage th
Raymond Hettinger wrote:
>>Yes, I now agree. This means that I'm withdrawing proposal A (new
>>method) and championing only B (a subclass that implements
>>__getitem__() calling on_missing() and on_missing() defined in that
>>subclass as before, calling default_factory unless it's None). I don't
>>
Hi,
I have two patches lying around here, please comment:
* I think I've submitted this one to the tracker, but can't remember:
It's for PySequence_SetItem and makes something like this possible:
tup = ([], )
tup[0] += [1]
I can upload it once more to allow review.
* One patch for stat
Tim Peters wrote:
> Speaking of which, a number of test failures over the past few weeks
> were provoked here only under -r (run tests in random order) or under
> a debug build, and didn't look like those were specific to Windows.
> Adding -r to the buildbot test recipe is a decent idea. Getting
Neal Norwitz wrote:
>>How many of those do you see when you ignore the warnings you get
>>while building the Carbon extensions? Those extensions wrap loads of
>>deprecated functions, each of which will give a warning.
>
>
> RIght:
> http://www.python.org/dev/buildbot/all/g4%20osx.4%20trunk/builds
[EMAIL PROTECTED] wrote:
> Ronald> How many of those do you see when you ignore the warnings you
> Ronald> get while building the Carbon extensions?
>
> skip> I see a bunch related to Py_ssize_t. Those have nothing to do
> skip> with Carbon. I don't see them on the gentoo build,
[EMAIL PROTECTED] wrote:
> Neal> IMO compiler warnings should generate emails from buildbot.
>
> It doesn't generate emails for any other condition. I think it should just
> turn the compilation section yellow.
It would be easy to run the builds with -Werror, making warnings let the
compil
Terry Reedy wrote:
> "Neal Norwitz" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
>>There's nothing to prevent buildbot from making debug builds, though
>>that is not currently done.
>
>
> Now that there are separate report pages for 2.4 and 2.5, you could add
> pages for deb
Martin> So what is your recipe: Add -r to all buildbots? Only to those
Martin> which have an 'a' in their name? Only to every third build?
Martin> Duplicating the number of builders?
Martin> Same question for --with-pydebug. Combining this with -r would
Martin> multiply the nu
Guido van Rossum wrote:
> Thanks! That worked.
>
> But shouldn't we try to fix setup.py to detect this situation instead
> of making loud clattering noises?
One of my concerns with the distutils build process is that it
takes failures lightly. Unlike make, it won't stop when an error
occurs, but
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
> addition.
I don't know whether I support the proposal or not, but in reading
Mark Russel's email,
Georg Brandl wrote:
> * I think I've submitted this one to the tracker, but can't remember:
> It's for PySequence_SetItem and makes something like this possible:
>
> tup = ([], )
> tup[0] += [1]
That definitely needs fixing:
py> tup = ([], )
py> tup[0] += [1]
Traceback (most recent call la
[EMAIL PROTECTED] wrote:
> Now that you've broken the buildbot page into two (trunk and 2.4) I assume
> breaking it down even further wouldn't be a major undertaking. If we can
> recruit a suitable number of boxes I see no particular reason you can't
> support a 2x, 4x, 8x or more increase in the
On Tue, 21 Feb 2006, Guido van Rossum wrote:
[...]
> If you're only interested in classifying the three specific built-ins
> you mention, I'd check for the presense of certain attributes:
> hasattr(x, "lower") -> x is a string of some kind; hasattr(x, "sort")
> -> x is a list; hasattr(x, "update")
Martin v. Löwis wrote:
> Georg Brandl wrote:
>> * I think I've submitted this one to the tracker, but can't remember:
>> It's for PySequence_SetItem and makes something like this possible:
>>
>> tup = ([], )
>> tup[0] += [1]
>
> That definitely needs fixing:
>
> py> tup = ([], )
> py> tup[
"Jeremy Hylton" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> If I recall the discussion correctly, Guido said he was open to a
> version of nested scopes that allowed rebinding.
Yes. Among other places, he said in
http://article.gmane.org/gmane.comp.python.devel/25153/match=ne
Greg Ewing wrote:
> I don't quite see the point here. Inside a bytes object,
> they would be stored 1 byte per byte. Nobody is suggesting
> that they would take up more than that just because
> a_bytes_object[i] happens to return an int.
Speaking of which, I suspect it'll be a lot more common to
> Speaking of which, I suspect it'll be a lot more common to need integer
> objects in the full range [0, 255] than it is now.
>
> Perhaps we should extend the pre-allocated integer objects to cover the
> full byte range.
+1
___
Python-Dev mailing list
Raymond Hettinger wrote:
>> Speaking of which, I suspect it'll be a lot more common to need
>> integer objects in the full range [0, 255] than it is now.
>>
>> Perhaps we should extend the pre-allocated integer objects to cover
>> the full byte range.
>
> +1
Want me to raise an SF request?
Tim
Delaney, Timothy (Tim) wrote:
>>> Perhaps we should extend the pre-allocated integer objects to cover
>>> the full byte range.
>>
>> +1
>
> Want me to raise an SF request?
Done. Item # 1436243.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@pytho
On 21 Feb 2006, at 21:13, Ian Bicking wrote:
> By rebinding operator, does that mean it is actually an operator?
> I.e.:
>
># Required assignment to declare?:
>chunk = None
>while chunk := f.read(1000):
>...
No, I think that "x := y" should be a statement not an expression
At 11:50 PM 2/21/2006 +0100, Morel Xavier wrote:
>Phillip J. Eby wrote:
>>The '.' would mean "this name, but in the nearest outer scope that
>>defines it". Note that this could include the global scope, so the
>>'global' keyword could go away in 2.5. And in Python 3.0, the '.' could
>>become *
Martin v. Löwis wrote:
> [EMAIL PROTECTED] wrote:
[...]
>
> So for multiplying this by 8, I would have to create 48 lines of
> Apache configuration, and use 24 TCP ports. This can be done, but
> it would take some time to implement. And who is going to look
> at the 24 pages?
This last point is t
Jeremy Hylton wrote:
> The names of naming statements are quite hard to get right, I fear.
My vote goes for 'outer'.
And if this gets accepted, remove 'global' in 3.0.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post
Josiah Carlson wrote:
> It doesn't seem strange to you to need to encode data twice to be able
> to have a usable sequence of characters which can be embedded in an
> effectively 7-bit email;
I'm talking about a 3.0 world where all strings are unicode
and the unicode <-> external coding is for th
Georg Brandl wrote:
> But why is that better than
>
> class namespace(object): pass
>
> def my_func():
> foo = namespace()
> (...)
Because then it would be extremely difficult for CPython to
optimise accesses to foo into local variable lookups.
--
Greg Ewing, Computer Science Dept, +-
Alex Martelli wrote:
> If we call the type autodict, then having the factory attribute named
> autofactory seems to fit.
Or just 'factory', since it's the only kind of factory
the object is going to have.
--
Greg Ewing, Computer Science Dept, +--+
Universit
Jeremy Hylton wrote:
> On 2/21/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
>
>>On 2/21/06, Bengt Richter <[EMAIL PROTECTED]> wrote:
>
>>>But to the topic, it just occurred to me that any outer scopes could be
>>>given names
>>>(including global namespace, but that would have the name global by
Fuzzyman wrote:
> I've had problems in code that needs to treat strings, lists and
> dictionaries differently (assigning values to a container where all
> three need different handling) and telling the difference but allowing
> duck typing is *problematic*.
You need to rethink your design so that
There are a number of features I'd like to see happen with Python's
tracing and profiling subsystems (but I don't have the C experience to
do it myself). I started to write an SF feature-request and then
realized it was too much for a single ticket. Maybe a PEP? All of these
would be make my latest
[Martin v. Löwis]
> So what is your recipe:
I don't have one. I personally always use -uall and -r, and then run
the tests 8 times, w/ and w/o -O, under debug and release builds, and
w/ and w/o deleting .py[co] files first. Because that last one almost
never finds problems anymore, perhaps it wo
Patch / Bug Summary
___
Patches : 385 open (-14) / 3067 closed (+25) / 3452 total (+11)
Bugs: 864 open (-59) / 5621 closed (+68) / 6485 total ( +9)
RFE : 211 open ( +2) / 200 closed ( +2) / 411 total ( +4)
New / Reopened Patches
__
GNU uses
While playing around with the defaultdict patch, adding __reduce__ to
make defaultdict objects properly copyable through the copy module, I
noticed that copy.py doesn't support copying function objects. This
seems an oversight, since the (closely related) pickle module *does*
support copying functi
>> Let me rephrase that. I assume the people digging through Py_ssize_t
>> issues have been looking at compilation warnings for platforms other
>> than Mac OSX.
Martin> In the buildbot log, I see only a single one of these, and only
Martin> in an OSX-specific module. So no -
"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
> > addition.
>
> I don't know whether I supp
Martin> So for multiplying this by 8, I would have to create 48 lines of
Martin> Apache configuration, and use 24 TCP ports. This can be done,
Martin> but it would take some time to implement.
I'm not too worried about that because it's a one-time cost. I'd be willing
to help out. J
> Alex Martelli wrote:
>
>> If we call the type autodict, then having the factory attribute named
>> autofactory seems to fit.
>
> Or just 'factory', since it's the only kind of factory
> the object is going to have.
Gack, no. You guys are drifting towards complete ambiguity.
You might as wel
Hi,
It seems that the Path module as currently defined leaves equality
testing up to the underlying string comparison. My guess is that this
is fine for Unix (maybe not even) but it is a bit lacking for Windows.
Should the path class implement an __eq__ method that might do some of
the following
Hello.
Historical question ;)
Anyone can explain why function timegm is placed into module calendar, not to
module time, where it would be near with similar
function mktime?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
Sergey> Historical question ;)
Sergey> Anyone can explain why function timegm is placed into module
Sergey> calendar, not to module time, where it would be near with
Sergey> similar function mktime?
Historical accident. ;-)
Skip
___
Py
On 2/21/06, Tim Peters <[EMAIL PROTECTED]> wrote:
>
> Since the most fruitful variations (IME) for finding code errors are
> using -r and running a debug build too, I'd change the current
> run-all-the-time recipes to:
>
> - Stop doing the second "without deleting .py[co]" run.
> - Do one run with
1 - 100 of 106 matches
Mail list logo
