Raymond Hettinger wrote:
>> - It would be unwise to have a default value that would be called if
>> it was callable: what if I wanted the default to be a class instance
>> that happens to have a _call_ method for unrelated reasons?
>> Callability is an elusive propperty; APIs should not attempt to
On Feb 21, 2006, at 6:53 AM, Bengt Richter 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
Defin
"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
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
Regards,
Bengt Richter
On Mon, 20 Feb 2006 11:09:48 -0800, Alex Martelli <[EMAIL PROTECTED]> wrote:
>
>On Feb 20, 2006, at 8:35 AM, Raymond Hettinger wrote:
>
>> [GvR]
>>> I'm not convinced by the argument
>>> that __contains__ should always return True
>>
>> Me either. I cannot think of a more useless behavior or one
> 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 already do this in today's Python with mutable variables i
"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
[Guido]
> ...
> What's the practical use case for not wanting __contains__() to
> function?
I don't know. I have practical use cases for wanting __contains__()
to function, but there's been no call for those. For an example,
think of any real use ;-)
For example, I often use dicts to represent
"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
Guido> But shouldn't we try to fix setup.py to detect this situation
Guido> instead of making loud clattering noises?
Here's a first-cut try at a setup.py patch:
http://python.org/sf/1435651
Unfortunately, I don't think distutils provides a clean way to detect
symbols the way config
On Fri, 2006-02-17 at 11:09 -0800, Guido van Rossum wrote:
> Thanks for all the constructive feedback. Here are some responses and
> a new proposal.
>
> - Yes, I'd like to kill setdefault() in 3.0 if not sooner.
A worthy goal, but not possible unless you want to break existing code.
I don't thin
I am considering developing a PEP for enabling a mechanism to assign to
free variables in a closure (nested function). My rationale is that with the advent of PEP 227
, Python
has proper nested lexical scopes, but can have undesirable behavior
(especially with new developers) when a user makes wan
On Feb 20, 2006, at 7:25 PM, Stephen J. Turnbull wrote:
>> "Martin" == Martin v Löwis <[EMAIL PROTECTED]> writes:
>
> Martin> Please do take a look. It is the only way: If you were to
> Martin> embed base64 *bytes* into character data content of an XML
> Martin> element, the resul
On Sat, 2006-02-18 at 12:53 +0100, Pierre Barbier de Reuille wrote:
> > Guido> Over lunch with Alex Martelli, he proposed that a subclass of
> > Guido> dict with this behavior (but implemented in C) would be a good
> > Guido> addition to the language.
I agree that .setdefault() is a w
On 2/20/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> Adam Olsen asked:
> > ... d.getorset(key, func) would work in your use cases?
>
> It is an improvement over setdefault, because it doesn't
> always evaluate the expensive func. (But why should every
> call have to pass in the function, when it is
> "Martin" == Martin v Löwis <[EMAIL PROTECTED]> writes:
Martin> Please do take a look. It is the only way: If you were to
Martin> embed base64 *bytes* into character data content of an XML
Martin> element, the resulting XML file might not be well-formed
Martin> anymore (if the
[Aahz]
> If you're willing to commit to running a buildbot, and the only thing
> preventing you is shelling out $$$ to Microsoft, send me e-mail. I'll
> compile a list to send to the PSF and we'll either poke Microsoft to
> provide some more free licenses or pay for it ourselves. This is what
> t
Thanks! That worked.
But shouldn't we try to fix setup.py to detect this situation instead
of making loud clattering noises?
--Guido
On 2/20/06, Bob Ippolito <[EMAIL PROTECTED]> wrote:
>
> On Feb 20, 2006, at 6:48 PM, Guido van Rossum wrote:
>
> > On OSX (10.4.4) the readline module in the svn H
On Feb 20, 2006, at 6:48 PM, Guido van Rossum wrote:
> On OSX (10.4.4) the readline module in the svn HEAD fails compilation
> as follows. This is particularly strange since the buildbot is green
> for OSX... What could be up with this?
>
> building 'readline' extension
-lots of build junk-
In A
On OSX (10.4.4) the readline module in the svn HEAD fails compilation
as follows. This is particularly strange since the buildbot is green
for OSX... What could be up with this?
building 'readline' extension
gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp
-mno-fused-madd -DNDEBUG -g -O3
On 2/20/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Have you considered the third alternative that's been
> mentioned -- a wrapper?
I don't like that at all. It's quite tricky to implement a fully
transparent wrapper that supports all the special methods (__setitem__
etc.). It will be slower. And
"Martin v. Löwis" wrote:
> Delaney, Timothy (Tim) wrote:
>> However, *because* Python uses duck typing, I tend to feel that
>> subclasses in Python *should* be drop-in replacements. If it's not a
>> drop-in replacement, then it should probably not subclass, but just
>> use duck typing (probably by
On 2/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> [stuff with typos]
Here's the proofread version:
I have a patch ready that implements this. I've assigned it to Raymond
for review. I'm just reusing the same SF patch as before:
http://python.org/sf/1433928 .
One subtlety: for maximal fle
On 2/20/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> > [Alex]
> >>> I see d[k]+=1 as a substantial improvement -- conceptually more
> >>> direct, "I've now seen one more k than I had seen before".
> >
> > [Guido]
> >> Yes, I now agree. This means that I'm withdrawing proposal A (new
> >> method)
in two ways:
1) dict.get doesn't work for object dicts or in exec/eval contexts, and
2) dict.get requires me to generate the default value even if I'm not
going to use it, a process which may be expensive.
On 2/20/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Crutcher Dunnavant ]
> >> There
On Feb 20, 2006, at 5:05 PM, Raymond Hettinger wrote:
> [Alex]
>>> I see d[k]+=1 as a substantial improvement -- conceptually more
>>> direct, "I've now seen one more k than I had seen before".
>
> [Guido]
>> Yes, I now agree. This means that I'm withdrawing proposal A (new
>> method) and champio
If you're willing to commit to running a buildbot, and the only thing
preventing you is shelling out $$$ to Microsoft, send me e-mail. I'll
compile a list to send to the PSF and we'll either poke Microsoft to
provide some more free licenses or pay for it ourselves. This is what
the PSF is for!
N
[Alex]
>> I see d[k]+=1 as a substantial improvement -- conceptually more
>> direct, "I've now seen one more k than I had seen before".
[Guido]
> Yes, I now agree. This means that I'm withdrawing proposal A (new
> method) and championing only B (a subclass that implements
> __getitem__() calling o
On Feb 20, 2006, at 3:04 PM, Brett Cannon wrote:
...
>> - "Yes and it should be the only constructor argument." This is my
...
> While #3 is my preferred solution as well, it does pose a Liskov
> violation if this is a direct dict subclass instead of storing a dict
How so? Liskov's pr
Trent Mick wrote:
> Look for:
> def find_platform_sdk_dir()
> here:
> http://cvs.sourceforge.net/viewcvs.py/pywin32/pywin32/setup.py?view=markup
>
> That is the best code I know for doing that.
Right; I was planning something similar (although I would probably
hard-code the 2003 SP1 regis
Bengt Richter wrote:
> On Sat, 18 Feb 2006 09:59:38 +0100,
> =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <[EMAIL PROTECTED]> wrote:
> Thinking about bytes recently, it occurs to me that bytes are really not
> intrinsically
> numeric in nature. They don't necessarily represent uint8's. E.g., a bin
Delaney, Timothy (Tim) wrote:
> However, *because* Python uses duck typing, I tend to feel that
> subclasses in Python *should* be drop-in replacements. If it's not a
> drop-in replacement, then it should probably not subclass, but just use
> duck typing (probably by wrapping).
Inheritance is more
Josiah Carlson wrote:
> If you're up for it, I'm up for it. It'll take me a bit to get the
> software on the machine. Want me to ping you when I get the toolset
> installed?
Sure! That should work fine. It would be best if the buildbot would
run with the environment variables all set up, so that
Greg Ewing wrote:
> In other words, just because A inherits from B in
> Python isn't meant to imply that an A is a drop-in
> replacement for a B.
Hmm - this is interesting. I'm not arguing Liskov violations or anything
...
However, *because* Python uses duck typing, I tend to feel that
subclasse
[Martin v. Loewis wrote]
> If you want to build extensions for this build using distutils, you
> need to
> ...
> 2. open an AMD64 retail shell
> ...
>
> It might be possible to drop 2) some day, but finding the SDK from
> the registry is really tricky.
Look for:
def find_platform_sdk_dir()
he
Brett Cannon wrote:
> While #3 is my preferred solution as well, it does pose a Liskov
> violation if this is a direct dict subclass
I'm not sure we should be too worried about that.
Inheritance in Python has always been more about
implementation than interface, so Liskov doesn't
really apply in
Regarding this Grammar change; (last October)
from argument: [test '=' ] test [gen_for]
to argument: test [gen_for] | test '=' test ['(' gen_for ')']
- to raise error for "bar(a = i for i in range(10)) )"
I think we should change it to
argument: test [gen_for] | test '=' te
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
Bengt Richter wrote:
> On Sat, 18 Feb 2006 23:33:15 +0100, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> note what base64 really is for. It's essence is to create a _character_
> sequence
> which can succeed in being encoded as ascii. The concept of base64 going
> str->str
> is really a mental sho
Martin v. Löwis wrote:
> Michael Foord wrote:
>
>> Has a machine been volunteered ?
>>
>
> Not yet.
>
>
>> I have a spare machine and an always on connection. Would the 'right'
>> development tools be needed ? (In the case of Microsoft they are a touch
>> expensive I believe.)
>>
Guido van Rossum wrote:
> I see two alternatives.
Have you considered the third alternative that's been
mentioned -- a wrapper?
The issue of __contains__ etc. could be sidestepped by
not giving the wrapper a __contains__ method at all.
If you want to do an 'in' test you do it on the
underlying d
On 2/20/06, Dan Gass <[EMAIL PROTECTED]> wrote:
> Why not have the factory function take the key being looked up as an
> argument?
This was considered and rejected already.
You can already customize based on the key by overriding on_missing()
[*]. If the factory were to take a key argument, we co
On 2/20/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> While #3 is my preferred solution as well, it does pose a Liskov
> violation if this is a direct dict subclass instead of storing a dict
> internally (can't remember the name of the design pattern that does
> this). But I think it is good to ha
On 2/20/06, Dan Gass <[EMAIL PROTECTED]> wrote:
> Why not have the factory function take the key being looked up as an
> argument? Seems like there would be uses to customize the default based on
> the key. It also forces you to handle list factory functions and constant
> factory functions (amon
[Steven Bethard]
> * Should default_factory be an argument to the constructor? The three
> answers I see:
>
> - "No." I'm not a big fan of this answer. Since the whole point of
> creating a defaultdict type is to provide a default, requiring two
> statements (the constructor call and the defaul
On 2/20/06, Raymond Hettinger <
[EMAIL PROTECTED]> wrote:
An alternative is to have two possible attributes: d.default_factory = listor d.default_value = 0with an exception being raised when both are defined (the test is done when theattribute is created, not when the lookup is performed).
Why n
On 2/20/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> I wrote:
> ># I want to do ``dd[item] += 1``
>
> Guido van Rossum wrote:
> > You don't need a new feature for that use case; d[k] = d.get(k, 0) + 1
> > is perfectly fine there and hard to improve upon.
>
> Alex Martelli wrote:
> > I see d[
I have now produces a snapshot of a Win64 build for AMD64
processors (also known as EM64T or x64); this is different
from IA-64 (which is also known as Itanium)...
Anyway, the binaries are
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.5.13199.amd64.msi
This is from today's trunk. If you
I wrote:
># I want to do ``dd[item] += 1``
Guido van Rossum wrote:
> You don't need a new feature for that use case; d[k] = d.get(k, 0) + 1
> is perfectly fine there and hard to improve upon.
Alex Martelli wrote:
> I see d[k]+=1 as a substantial improvement -- conceptually more
> direct, "I'v
Michael Foord wrote:
> Has a machine been volunteered ?
Not yet.
> I have a spare machine and an always on connection. Would the 'right'
> development tools be needed ? (In the case of Microsoft they are a touch
> expensive I believe.)
Any build process would do. I would prefer to see the offi
Jan Claeys wrote:
>>That, in turn, is because nobody is so short of disk space that
>>you really *have* to share /usr/share across architectures,
>
>
> I can see diskless thin clients that boot from flash memory doing things
> like that? (E.g. having documentation and header files and other
> l
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 them.
Well, the cost of Unic
Martin v. Löwis wrote:
> Steve Holden wrote:
>> All formats would be improved of the headers could be made to float at
>> the top of the page as scrolling took place.
>
> Can this be done in CSS? If so, contributions are welcome.
Not as it is. The big table would have to be split so that there i
Steve Holden wrote:
> All formats would be improved of the headers could be made to float at
> the top of the page as scrolling took place.
Can this be done in CSS? If so, contributions are welcome. If not,
can somebody prepare a modified page with the necessary changes
(preferably only additiona
Guido van Rossum wrote:
> They don't; I think a separate page would be a fine idea.
Ok, I have now split this into three pages.
> FWIW, it looks like all the sample templates are still wasting a lot
> of horizontal space in the first two columns the second is almost
> always empty. Perhaps the au
On Mon, Feb 20, 2006, Alex Martelli wrote:
> On Feb 20, 2006, at 12:38 PM, Aahz wrote:
> ...
>>> Can you say, for the record (since nobody else seems to care), if
>>> d.getorset(key, func) would work in your use cases?
>>
>> Because I haven't been reading this thread all that closely, you'll
Guido van Rossum wrote:
> Why are you so keen on using a dictionary to share data between
> threads that may both modify it? IMO this is asking for trouble --
> the advice about sharing data between threads is always to use the
> Queue module.
I use them often for a shared caches. But yeah, it's
Stephen J. Turnbull wrote:
> Martin> For an example where base64 is *not* necessarily
> Martin> ASCII-encoded, see the "binary" data type in XML
> Martin> Schema. There, base64 is embedded into an XML document,
> Martin> and uses the encoding of the entire XML document. As a
> M
[Crutcher Dunnavant ]
>> There are many times that I want d[key] to give me a value even when
>> it isn't defined, but that doesn't always mean I want to _save_ that
>> value in the dict.
How does that differ from the existing dict.get method?
Raymond
___
On 2/20/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
>
> On Feb 20, 2006, at 12:33 PM, Guido van Rossum wrote:
> ...
> > You don't need a new feature for that use case; d[k] = d.get(k, 0) + 1
> > is perfectly fine there and hard to improve upon.
>
> I see d[k]+=1 as a substantial improvement --
On 2/20/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Also, is default_factory=list threadsafe in the same way .setdefault is?
> That is, you can safely do this from multiple threads:
>
>d.setdefault(key, []).append(value)
>
> I believe this is safe with very few caveats -- setdefault itself i
On Feb 20, 2006, at 12:38 PM, Aahz wrote:
...
>> Can you say, for the record (since nobody else seems to care), if
>> d.getorset(key, func) would work in your use cases?
>
> Because I haven't been reading this thread all that closely, you'll
> have
> to remind me what this means.
Roughly the
On Feb 20, 2006, at 12:33 PM, Guido van Rossum wrote:
...
> You don't need a new feature for that use case; d[k] = d.get(k, 0) + 1
> is perfectly fine there and hard to improve upon.
I see d[k]+=1 as a substantial improvement -- conceptually more
direct, "I've now seen one more k than I had
On 2/20/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Would it be deprecated in 2.*, or start deprecating in 3.0?
3.0 will have no backwards compatibility allowances. Whenever someone
says "remove this in 3.0" they mean exactly that. There will be too
many incompatibilities in 3.0 to be bothered wi
Steven Bethard wrote:
>>Alternative A: add a new method to the dict type with the semantics of
>>__getattr__ from the last proposal, using default_factory if not None
>>(except on_missing is inlined).
>
>
> I'm not certain I understood this right but (after
> s/__getattr__/__getitem__) this seems
Alex Martelli wrote:
>>I prefer this approach over subclassing. The mental load from an
>>additional
>>method is less than the load from a separate type (even a
>>subclass). Also,
>>avoidance of invariant issues is a big plus. Besides, if this allows
>>setdefault() to be deprecated, it beco
Manuzhai wrote:
>> No; nobody volunteered a machine yet (plus the hand-holding that
>> is always necessary with Windows).
>>
>
> What exactly is needed for this? Does it need to be a machine dedicated
> to this stuff, or could I just run the tests once every day or so when I
> feel like it a
On 2/20/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> "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
On Mon, Feb 20, 2006, Adam Olsen wrote:
> On 2/20/06, Aahz <[EMAIL PROTECTED]> wrote:
>> On Sun, Feb 19, 2006, Josiah Carlson wrote:
>>>
>>> I agree, there is nothing perfect. But at least in all of my use-cases,
>>> and the majority of the ones I've seen 'in the wild', my previous post
>>> provid
I'm thinking something mutch closer to this (note default_factory gets the key):
def on_missing(self, key):
if self.default_factory is not None:
value = self.default_factory(key)
if self.on_missing_define_key:
self[key] = value
return value
raise KeyError(key)
On 2/20/06, Cr
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Terry Reedy wrote:
>> With a couple of more machines added, should there be two separate pages
>> for trunk and 2.4 builds? Or do most checkins affect both?
>
> I'd like to avoid this, assuming that people only loo
Sorry to chime in so late, but why are we setting a value when the key
isn't defined?
It seems there are many situations where you want:
a) default values, and
b) the ability to determine if a value was defined.
There are many times that I want d[key] to give me a value even when
it isn't def
On 2/20/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Alternative A: add a new method to the dict type with the semantics of
> > [__getitem__] from the last proposal, using default_factory if not None
> > (except on_missing is inlined).
>
> I'm not certain I understood
Yes, this is the type of thing we've been struggling with for years.
There used to be way more of these. I can't guarantee it'll be fixed
with priority (it's mostly of the "then don't do that" type) but
please do file a bug so someone with inclination can fix it. The same
happens for deeply recursi
"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
Just noticed this and wondered if it came under the Python should never
crash mantra. Should sys.getrecursionlimit() perhaps be taken into
account somewhere?
>>> D = {'a': None}
>>> for i in xrange(15):
... D = {'a': D}
...
>>> D
{'a': {'a': {'a': {'a': {'a': {'a':
Guido van Rossum wrote:
> Alternative A: add a new method to the dict type with the semantics of
> __getattr__ from the last proposal, using default_factory if not None
> (except on_missing is inlined).
I'm not certain I understood this right but (after
s/__getattr__/__getitem__) this seems to sug
On Feb 20, 2006, at 8:35 AM, Raymond Hettinger wrote:
> [GvR]
>> I'm not convinced by the argument
>> that __contains__ should always return True
>
> Me either. I cannot think of a more useless behavior or one more
> likely to have
> unexpected consequences. Besides, as Josiah pointed out, it
Adam Olsen asked:
> ... d.getorset(key, func) would work in your use
> cases?
It is an improvement over setdefault, because it
doesn't always evaluate the expensive func. (But
why should every call have to pass in the function,
when it is a property of the dictionary?)
It doesn't actually *solve
On 2/20/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [GvR]
> > Alternative A: add a new method to the dict type with the semantics of
> > __getattr__ from the last proposal
>
> Did you mean __getitem__?
Yes, sorry, I meant __getitem__.
--
--Guido van Rossum (home page: http://www.python.org
Op vr, 17-02-2006 te 23:22 +0100, schreef "Martin v. Löwis":
> That, in turn, is because nobody is so short of disk space that
> you really *have* to share /usr/share across architectures,
I can see diskless thin clients that boot from flash memory doing things
like that? (E.g. having documentat
On 2/20/06, Aahz <[EMAIL PROTECTED]> wrote:
> On Sun, Feb 19, 2006, Josiah Carlson wrote:
> >
> > I agree, there is nothing perfect. But at least in all of my use-cases,
> > and the majority of the ones I've seen 'in the wild', my previous post
> > provided an implementation that worked precisely
On Mon, 20 Feb 2006 12:01:02 +, "Paul Moore" <[EMAIL PROTECTED]> wrote:
>On 2/19/06, Steve Holden <[EMAIL PROTECTED]> wrote:
>> > You are missing the rationale of the PEP process. The point is
>> > *not* documentation. The point of the PEP process is to channel
>> > and collect discussion, so
> "Josiah" == Josiah Carlson <[EMAIL PROTECTED]> writes:
Josiah> I try to internalize it by not thinking of strings as
Josiah> encoded data, but as binary data, and unicode as text. I
Josiah> then remind myself that unicode isn't native on-disk or
Josiah> cross-network (which
Martin v. Löwis wrote:
> John Marshall wrote:
>
>>Should I expect the virtual memory allocation
>>to go up if I do the following?
>
>
> python-dev is a list for discussing development of Python,
> not the development with Python. Please post this question
> to [EMAIL PROTECTED]
>
> For python-d
On Mon, 20 Feb 2006 05:41:43 -0800, "Guido van Rossum" <[EMAIL PROTECTED]>
wrote:
>I'm withdrawing the last proposal. I'm not convinced by the argument
>that __contains__ should always return True (perhaps it should also
>insert the value?), nor by the complaint that a holy invariant would
>be vi
>>> 1/2
0
>>> (-1) ** (1./2)
Traceback (most recent call last):
File "", line 1, in ?
ValueError: negative number cannot be raised to a fractional power
Regards,
Michael
On 2/20/06, Jonathan Barbero <[EMAIL PROTECTED]> wrote:
> Hello!
> My name is Jonathan, i´m new with Python.
>
>I try
[GvR]
> I'm not convinced by the argument
> that __contains__ should always return True
Me either. I cannot think of a more useless behavior or one more likely to
have
unexpected consequences. Besides, as Josiah pointed out, it is much easier for
a subclass override to substitute always True
On 2/16/06, John Marshall <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Should I expect the virtual memory allocation
> to go up if I do the following?
> -
> raw = open("data").read()
> while True:
> d = eval(raw)
> -
>
> I would have expected the memory allocated to the
> object referenced
On Feb 20, 2006, at 5:41 AM, Guido van Rossum wrote:
...
> Alternative A: add a new method to the dict type with the semantics of
> __getattr__ from the last proposal, using default_factory if not None
> (except on_missing is inlined). This avoids the discussion about
> broken invariants, but o
2006/2/20, Jonathan Barbero <[EMAIL PROTECTED]>:
> Hello!
> My name is Jonathan, i´m new with Python.
Hello Jonathan. This list is only for developing Python itself, not
for developing in Python.
You should address this kind of question in comp.lang.python
(available as a newsgroup and a maili
Georg,
Please do not respond to off-topic posts on python-dev without
redirecting them to comp.lang.python (or other suitable place). Thanks!
On Mon, Feb 20, 2006, Georg Brandl wrote:
>
> Jonathan Barbero wrote:
>> Hello!
>> My name is Jonathan, i?m new with Python.
>>
>>I try this in th
Jonathan Barbero wrote:
> Hello!
> My name is Jonathan, i´m new with Python.
>
>I try this in the command line:
>
>>>> (-1)**(1/2)
> 1
>
>This is wrong, i think it must throw an exception.
> What do you think?
>>> 1/2
0
>>> (-1)**0
1
It's fine.
If you want to get a flo
On Sun, Feb 19, 2006, Josiah Carlson wrote:
>
> I agree, there is nothing perfect. But at least in all of my use-cases,
> and the majority of the ones I've seen 'in the wild', my previous post
> provided an implementation that worked precisely like desired, and
> precisely like a regular dictionar
Hello! My name is Jonathan, i´m new with Python. I try this in the command line: >>> (-1)**(1/2) 1 This is wrong, i think it must throw an exception. What do you think?
Bye. Jonathan.
___
Python-Dev mailing list
Python-Dev@py
Guido van Rossum wrote:
> FWIW, it looks like all the sample templates are still wasting a lot
> of horizontal space in the first two columns the second is almost
> always empty. Perhaps the author of the change could be placed *below*
> the timestamp instead of next to it? Also for all practical p
On Sat, 18 Feb 2006 23:33:15 +0100, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>On Sat, Feb 18, 2006 at 01:21:18PM +0100, M.-A. Lemburg wrote:
>
[...]
>> > - The return value for the non-unicode encodings depends on the value of
>> >the encoding argument.
>
>> Not really: you'll always get a b
I'm withdrawing the last proposal. I'm not convinced by the argument
that __contains__ should always return True (perhaps it should also
insert the value?), nor by the complaint that a holy invariant would
be violated (so what?).
But the amount of discussion and the number of different viewpoints
Jeff Rush wrote:
> Guido van Rossum wrote:
>> On 2/19/06, Jeff Rush <[EMAIL PROTECTED]> wrote:
>> [Quoting Neal Norwitz]
>>
I've heard of a bunch of people using --disable-unicode. I'm not sure
if it's curiosity or if there are really production builds without
unicode. Ask this on
On 2/19/06, Steve Holden <[EMAIL PROTECTED]> wrote:
> > You are missing the rationale of the PEP process. The point is
> > *not* documentation. The point of the PEP process is to channel
> > and collect discussion, so that the BDFL can make a decision.
> > The BDFL is not bound at all to the PEP pr
1 - 100 of 103 matches
Mail list logo
