its, but that's a subject for the Python-3000
mailing list; as long as builtins and globals stay as fluid as today,
I'm skeptical on the optimization opportunities here.
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Aug 23, 2006, at 3:29 PM, Thomas Wouters wrote:
>
> Since Alex isn't on python-dev, forwarding this for his convenience
> (he said he wanted to reply.)
Thanks! I _am_ on Python-Dev (otherwise couldn't read what you're
forwarding here), but not on Python-Checki
le, if the 1990 C Standard is that much
weaker on this than 1999's and we need to stick to it anyway. But
the problem is that testing this sensibly requires fpconst (from PEP
754) or the equivalent, otherwise it may be impossible to write
unittest to show the presence or absence of
when the callable in turn keeps alive an object with possibly massive
state). In practice I use wrapping and tricks, but it would be nice to
have cleaner standard library support for this. (Often the container
needs to be some form of a Queue.Queue, since
ecuted many times, but it isn't the only case.
>
> You cannot assume that optimization techniques used on other (static)
languages can be used/ported in Python.
>
> Cesare
>
No, it's singularly impossible to prove that any global load will be any given
value
; Cheers,
> Nick.
>
> --
> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
>
Ugh, I can't be the only one who finds these special cases to be a little
nasty?
Special cases aren't special enough to break the rules.
Alex
--
"I disapprove of what
ly don't think of themselves
as "developers"; they're more likely to end up, say, as "CHI experts",
"computational linguists", and the like...
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
>
> Cool, thanks.
I'd like to volunteer for Italian (and we, the Italian Python
community, do have reasonably good connections to the Italian
technical press, which is covering e.g. the upcoming Pycon Due
conference), and although my French is VERY rusty I can give it a try
if no nati
PyString - bytes
> PyBytes - bytearray
>
> See? :)
Yep, but please do keep the PyUnicode for str and PyString for bytes
(as macros/synonnyms of PyStr and PyBytes if you want!-) to help the
task of porting existing extensions... the bytearray functions should
On Sun, Mar 2, 2008 at 10:39 AM, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
>
> On 3/2/08, Christian Heimes <[EMAIL PROTECTED]> wrote:
> > Alex Martelli wrote:
> > > Yep, but please do keep the PyUnicode for str and PyString for bytes
> > > (as macros/
just announced new investments and
high-profile hires to make Jython a top-quality Python implementation.
Alex
On Sun, Mar 9, 2008 at 7:42 AM, <[EMAIL PROTECTED]> wrote:
>
> Michal> I'm about to start my master thesis: "optimizing python
> Michal> interpreter&
Your
proposal can't play well with slices including negative indices.
Also, your desired use case of alist[indices] is already pretty well
covered by [alist[i] for i in indices].
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.py
kage appears to offer an easy
way to migrate threaded code to multiple-processes approaches,
although I've only played around with it, not [yet] used it for
production code).
Alex
On Wed, Mar 19, 2008 at 10:49 AM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 19, 2008 at
oded strings).
+1 -- it seems very practical as well as consistent, and I see no downsides.
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/
On Fri, May 2, 2008 at 4:11 PM, Jesse Noller <[EMAIL PROTECTED]> wrote:
> +1 from me
+2 from me -- of all abuses of lambdas, this one's the worst.
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listi
e simple "return " [[or bool() if it's
actually mandatory to return a bool and can't be relied
upon to produce one]].
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
PI
> we can tap into in order to create new issues.
Given the app engine model, I guess any "API" to an app engine-hosted
service would have to be of the RESTful kind, i.e., some URLs to which
client-code can POST appropriately.
Alex
_
be placed *outside the current function*?! What a straw-man...! Just
do
def last_first(r): return r[0].lower(), r[5].lower()
for k, g in groupby(iterable, key=last_first): ...
putting the def right where you now have the " = lambda ..." of course!
Alex
___
hewing synonyms in APIs
you design that provide no added value beyond that of catering to
different tastes or to a meta-taste for variety over uniformity;-) is
still a helpful heuristic -- with or without the "obvious" word (i.e.,
whether you're working with C, which doesn't hav
ame way: it WOULD be sad to waste this
excellent opportunity, so I second the suggestion to put pyprocessing
in the library right now.
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
h
an extension
from having to write that unneeded and slow extra code?
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
often used in dotNET
libraries)?
Alex
On Mon, Jun 9, 2008 at 1:28 AM, Michael Foord <[EMAIL PROTECTED]> wrote:
> Steven D'Aprano wrote:
>>
>> On Mon, 9 Jun 2008 12:24:55 pm Curt Hagenlocher wrote:
>>
>>
>>>
>>> So, it's okay to seta
esses to identifiers without leading dots doing nested
lookup (so that e.g. "print foo" might emit b.foo if present, else
a.foo if present, else local foo if present, else global foo if
present).
I'm not sure I like this whole arrangement, but maybe overall I do,
perhaps +0 ...
Ale
often,
even though many of those cases don't make it into YouTube videos). I
don't need to rant against it within Google, because Google's Python
Style Guide already absolutely forbids it, fortunately;-).
Alex
___
Python-D
gnments
define local variables, as usual -- but you can say e.g. 'zz' to mean
'someobj.zz', if you're sufficiently keen on giving up the advantage
of having many well-separated namespaces;-).
Alex
On Sat, Jun 14, 2008 at 11:16 PM, Cesare Di Mauro <[EMAIL PROTECTED]>
ast, I'll admit -- it never
feels as free-flowing as Scheme did back when I used THAT, but, close
enough to make my jobs successful!-)
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
x pair using the C99 notation as
> recommended in 754R?
Dunno about everyone, but I'm +1 on that.
> Are you thinking of math module functions or as a method and classmethod on
> floats?
I'd prefer math modules functions.
Alex
___
...
+1 : enriching the existing method in a way that's perfectly
transparent and innocuous to all existing uses _feels_ right, because
it's more practical.
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
I thought that's what we had __index__ for -- reject arguments that
don't SMOOTHLY turn into integers when an integer is actually
required!
Alex
On Mon, Jul 21, 2008 at 10:01 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> Well, the real problem is os.urandom
bad...:
"""Mixin to enable reification."""
def __init__(self):
super(ReificationStore, self).__init__()
[there's *nothing else* in this __init__!].
Alex
___
Python-Dev mailing list
Python-Dev@p
On Tue, Aug 26, 2008 at 10:24 PM, Michele Simionato
<[EMAIL PROTECTED]> wrote:
...
> .. code-block:: python
>
> def include_mixin(mixin, cls): # could be extended to use more mixins
> # traits as in Squeak take the precedence over the base class
> dic = vars(mixin).copy() # could be ext
AIX 3 was). Sad to learn that BSD is now also broken in
the same way:-(.
Alex
On Wed, Sep 17, 2008 at 8:00 AM, James Y Knight <[EMAIL PROTECTED]> wrote:
>
> On Sep 17, 2008, at 10:53 AM, Andrew MacIntyre wrote:
>
>> Martin v. Löwis wrote:
>>>>
>>>&
) and that requires Python 2.5 and only pure-Python
add-ons... thanks!
Alex
On Wed, Sep 24, 2008 at 8:08 AM, Bob Ippolito <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 24, 2008 at 6:14 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
&g
l it's missing is a simple code review tool like code.google.com's
or Rietveld, but Jesper's promised me he would integrate something to
that effect...
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailma
ely said I could see
> some advantages to it. I spent most of my post telling the OP why I
> thought his arguments were wrong!
And now we're telling you why we think your arguments are also wrong
-- what else do you expect from python-dev after all?
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
rapper generator he's also authored and uses for PyQt) AND
it would make sip even better, so he may want to put it on his
backlog.
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
h
I wonder if there's some desiderata left for future Python versions to
make this standard behavior easier (for C-coded, Python-coded, and
Cython-coded classes, ones made by SWIG, etc) without too much black
magic...
Alex
On Mon, Dec 1, 2008 at 1:30 AM, Filip Gruszczyński <[EMAIL P
, and once you're done it reuses
it's buffer to create the Python level string object, which is to say
there's no need to copy it at the end.
As I said, unless your interest is maximum performance, there's nothing wrong
with the current idiom, and
Therefore I think these should be considered application issues, since request
limiting is difficult and error prone, I'd recommend the Python stdlib including
a non-hash based map (such as a binary tree).
Alex
___
Python-Dev mailing list
Python-De
e easy to just:
$ pypy -mtimeit "import struct"
$ pypy -mtimeit -s "import importlib" "importlib.import_module('struct')"
Or whatever the right API is.
Alex
___
Python-Dev mailing list
Python-Dev@python.
use a different internal implementation (while, of course,
still being dicts at the Python level). We do *not* handle the case of
trying to figure out whether a Python object is immutable in any way.
Alex
___
Python-Dev mailing list
Python-Dev@python.org
linux-gnu/libz.so.1 (0x7f3e32d8f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f3e32b0b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f3e3276b000)
/lib64/ld-linux-x86-64.so.2 (0x7f3e33c03
Stefan Krah wrote:
> Alex Leach wrote:
> > I've managed to compile everything in the python distribution except for
> > Modules/_ctypes/libffi/src/x86/ffi64.c.
>
> There is an issue for this:
>
> http://bugs.python.org/issue4130
Yes, I saw that bug report, bu
Stefan Krah wrote:
> Alex Leach wrote:
> > I've managed to compile everything in the python distribution except for
> > Modules/_ctypes/libffi/src/x86/ffi64.c.
>
> There is an issue for this:
>
> http://bugs.python.org/issue4130
Yes, I saw that bug report, bu
uild_ext
But this then uses gcc-specific flags when compiling.
Cheers,
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Stefan Krah wrote:
> Alex Leach wrote:
> > I've managed to compile everything in the python distribution except for
> > Modules/_ctypes/libffi/src/x86/ffi64.c.
>
> There is an issue for this:
>
> http://bugs.python.org/issue4130
Yes, I saw that bug report, bu
s cf. <3s).
And the script hardly took that long to write!
Thanks for the benchmark recommendation; I'll use that on the next build -
hopefully after passing the math tests!
Cheers,
Alex
>
___
Python-Dev mailing list
Python-Dev@python.org
h
l/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/intel/bin:/usr/intel/composer_xe_2011_sp1.9.293/mpirt/bin/intel64:/home/albl500/SDKs/android-sdk-linux/tools:/biol/bin:/biol/arb/bin:/usr/local/cuda/bin:/home/albl500/bin:/usr/intel/composer_xe_2011_sp1.9.293/mpirt/bin/intel64
LD=xild
CXX=icpc
CC=ic
lookups, from the module I'm working on.
That way I hope I can pass method="svg" to ElementTree's write() method; it
should work, and it should also be backwards-compatible.
That should be quite a quick and easy fix actually. Would this be something
worth in
On Tuesday 08 May 2012 23:15:43 And Clover wrote:
|
| CDATA sections are of use for hand-authoring readability, but don't help
| in machine-serialised documents. You don't get away from the need to
| encode out-of-band sequences (notably ]]> is still invalid) so it
| doesn't buy you any simplicity
heck that though..
|
| As to writing a loop in javascript without < and >, == and != generally
| work rather well, as does Array.prototype.forEach[0]
Thanks for the tips!
Cheers,
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http:/
heck that though..
|
| As to writing a loop in javascript without < and >, == and != generally
| work rather well, as does Array.prototype.forEach[0]
Thanks for the tips!
Cheers,
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http:/
Frank Wierzbicki seemed positive about it.
> -eric
>
I'm +1 on such a list, I don't have the time to follow every single thread on
python-dev, and I'm sure I miss a lot of things, have a dedicated place for
things I know are rele
r me, or anyone else apparently)
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Tue, Jun 12, 2012 at 11:47 AM, Brett Cannon wrote:
>
>
> On Tue, Jun 12, 2012 at 12:38 PM, Alex Gaynor wrote:
>
>> For PyPy: I'm not an expert in our import, but from looking at the source
>>
>> 1) imp.cache_from_source is unimplemented, it's an Attri
your opinion. I understand the
frustration, but we have to let people succeed and/or fail on their own[2].
It worked with the OS packagers guys though, we have built a great data
files managment system in packaging + the versions (386)
Are you referring to "the" packaging/dis
et's let setuptools be setuptools and distribute be distribute i.e. as
long as distribute exists, I don't care at all about setuptools' release
schedule (c.f. PIL/Pillow) and I like it that way :-). If one day
setuptools or packaging/distutils2 comes alon
distutils[1], a package is: a module or modules inside
another module[2]. So e.g.::
foo.py is a module
and:
foo/__init__.py
foo/foo.py
is a simple package containing the following modules:
import foo, foo.foo
Alex
[1]
http://docs.python.org/distutils/introduction.html#general
100% convinced the new term should be "dist". Rather I propose:
- Change the definition of package to: a module (or modules) plus
package data and package metadata inside another module.
- Refer to source dists as "source packages" i.e. packages containing
source code.
Hi all,
I've just submitted a PEP proposing making __length_hint__ a public API for
users to define and other VMs to implement:
PEP: 424
Title: A method for exposing a length hint
Version: $Revision$
Last-Modified: $Date
Author: Alex Gaynor
Status: Draft
Type: Standards Track
Content
On Sat, Jul 14, 2012 at 4:18 PM, Benjamin Peterson wrote:
> 2012/7/14 Alex Gaynor :
> >
> > Proposal
> >
> >
> > This PEP proposes formally documenting ``__length_hint__`` for other
> > interpreter and non-standard library Python to implement.
>
hint computed. e.g. imagine
some sort of lazy stream that cached itself, and only wanted to offer a
length hint if it had already been evaluated. Without an exception to
raise, it has to return whatever the magic value for length_hint is (in
your impl it appears to be 0, the current _PyObject_Len
y the current C _PyObject_LengthHint implementation.
There are no provisions for infinite iterators, that is not within the scope of
this proposal.
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pytho
nd the speedups are
tiny.
Please, learn from Unladen Swallow and other's experiences, otherwise they're
for naught, and frankly we (python-dev) waste a lot of time.
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.
ized to compile individual functions,
recursion, etc. And any profiling JIT, in practice, needs a compile heuristic
for how many calls must occur before a unit is compiled, even the Hotspot JVM
has one.
Alex
___
Python-Dev mailing list
Python-Dev@
Hi all,
The discussion on PEP 0424 seems to have subsided (and I haven't gotten angry
emails in a week!). So I would like to request a BDFL or BDFP pronouncement
on PEP 0424, text available here:
http://hg.python.org/peps/file/tip/pep-0424.txt
everyone could take a new
look at that I would be very grateful. Sorry for the mixup.
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/
asonable, rather than try to spec that out precisely in the
pseudocode (aka Python ;)) a note like you suggest sounds good.
> --
> --Guido van Rossum (python.org/~guido)
>
Alex
--
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice H
hing proposed there is possible, b) making this a front-and-center API
makes it really easy to shoot themselves in the foot, by doing things like
breaking Python with invalid optimizations (hint: almost every optimization
proposed in that thread is invalid in th
Stefan Behnel behnel.de> writes:
> Right. If that makes a difference, it's another bug.
>
> Stefan
>
>
It's fixed, with, I will note, fewer lines of code than many messages in this
thread:
https://bitbucket.org/pypy/pypy/changeset/c30cb1dcb7
lly reading python-dev again
after all these months -- almost caught up with recent traffic
too;-)...
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/ma
might be substantial overhead). OK, I
guess, as long as we don't expect any further attribute setting on f to
affect C.f or D.f (and I don't know of any real use case where that
would be needed).
Alex
___
Python-Dev mailing list
Pyth
e proposing make it MORE
attractive to Apple to go for 2.3.5, LESS so, or is it indifferent from
their POV...?
Thanks in advance for any help in getting the tradeoffs about this
clearer in my mind!
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://
ag as ast_branch (while it wants a dash, NOT an
underscore...). I guess having the instructions recommended to me
again prompted me to doublecheck character by character extracarefully,
so, thanks!-)
Alex
___
Python-Dev mailing list
Python-Dev
sense of the speed or lack thereof of 2.3.x
releases' entrance in Tiger's previews...
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/
, we'd need some
performance measurements from real-life use cases) even though from the
point of view of code simplicity, in this example, there appears to be
little or no gain wrt slicing rec[offs:offs+itemsize] or using
buffer(rec, offs, itemsize).
Alex
d concrete ;-).
Your title "Python's Super Considered Harmful" is an obvious reference
to
and takeoff on Dijkstra's influential polemic "Goto Considered
Harmful".
...or any other of the 345,000 google hits on "considere
uire it, right? Can't we treat this misbehavior as an outright bug?
+1 -- the nonremoval of escape characters smells like a bug to me, too.
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
U
st it
here, rather than relying on would-be commenters to get it from CVS...
I'm also specifically CC'ing Clark, the co-author, since he wasn't
involved in this rewrite and of course I owe it to him to change or
clearly attribute to myself anything he doesn't like to have &
On 2005 Jan 10, at 18:43, Phillip J. Eby wrote:
...
At 03:42 PM 1/10/05 +0100, Alex Martelli wrote:
The fourth case above is subtle. A break of substitutability can
occur when a subclass changes a method's signature, or restricts
the domains accepted for a method's arg
ually
corresponds to the subset of PEP 246 adaptation for cases where
adapt() returns the original object or raises an error. (That is, if
adapt() could only ever return the original object or raise an error,
it would be precisely equivalent to Java casting, if I understand it
correctly.) Thus, at
s useless. If older code
doesn't have __conform__, it cannot possibly *use* the
Liskov-violation mechanism.
Adding __conform__ to a class to raise a LiskovViolation when needed is
a TINY change compared to the refactoring needed to use
template-meth
On 2005 Jan 10, at 23:15, Thomas Heller wrote:
Alex Martelli <[EMAIL PROTECTED]> writes:
PEP: 246
Title: Object Adaptation
Minor nit (or not?): You could provide a pointer to the Liskov
substitution principle, for those reader that aren't too familiar with
that term.
Excellent i
lent, you're really pushing people to use much more
complicated and sophisticated structures of objects than "private
inheritance" affords when properly used... and the LAST thing OO
programmers need is any encouragement towards more complicated
structures!-)
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
prior art, so thanks for pointing it out.
If interfaces change so often that 'n' can become worryingly high, this
is a valid concern. In my world, though, published interfaces do NOT
change as often as to require such remedies;-).
Alex
__
On 2005 Jan 11, at 11:01, Alex Martelli wrote:
On 2005 Jan 10, at 18:59, Phillip J. Eby wrote:
At 12:43 PM 1/10/05 -0500, Phillip J. Eby wrote:
As a practical matter, all of the existing interface systems (Zope,
PyProtocols, and even the defunct Twisted implementation) treat
interface
rt pro and con
args, too, but I'm not unbiased enough to write it all by myself...;-)
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pyt
or it) and
striving horrendously to shoehorn it in. So what's the score now...?
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-d
transitivity) is a violation
of PRAGMATICS, of the BEST-EFFORT implication, just as it would be to
drop packets once in a while in a TCP/IP stack due to some silly
programming bug which was passed silently.
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On 2005 Jan 11, at 20:48, Phillip J. Eby wrote:
...
I'd rather not assume that class inheritance implies substitutability,
Hm, you should take that up with Alex then, since that is what his
current PEP 246 draft does. :) Actually, the earlier drafts did that
too, so I'm not su
#x27;s worrisome, not just that nobody else reported problems, but
also that the unit tests didn't catch them...:-(
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
rmance enhancement while adding a related
feature (copy_reg integration), rather than as a fix for possible
metaconfusion, even though it also has that effect.)
OK, but if Armin is correct about the code in the reference
implementation of pep 246, and I think he is, this is still a bug in
copy.
__metaclass__ = MetaCopyableClass
# rest of class snipped
x = CopyableClass()
import copy
y = copy.copy(x)
kallisti:/tmp alex$ python x.py
Traceback (most recent call last):
File "x.py", line 14, in ?
y = copy.copy(x)
File "/usr/local/lib/python2.4/copy.py", line 79, in copy
ngth, such as A->B->C or A->Z->C, with all the steps being
declared lossless and perfect, then it SHOULD just pick one by whatever
criterion, since both will be equally perfect anyway -- so maybe my
reasoning by absurd wasn't totally absurd after all;-).
Would this compromise be
of course, and then
it should probably be made fast).
Feedback welcome -- the actual patch will doubtless be tiny, but it
would be nice to have it right the first time (as it needs to go into
both the 2.3 and 2.4 bugfix branches and the 2.5 head).
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
for
__deepcopy__.
The fix, again, should be a tiny patch -- and it seems to me that we
should have it for 2.3.5 as well as for 2.4.1 and the HEAD.
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On 2005 Jan 12, at 14:44, Paul Moore wrote:
On Wed, 12 Jan 2005 00:33:22 +0100, Alex Martelli <[EMAIL PROTECTED]>
wrote:
But adaptation is not transmission! It's PERFECTLY acceptable for an
adapter to facade: to show LESS information in the adapted object than
was in the orig
On 2005 Jan 12, at 15:00, Paul Moore wrote:
On Wed, 12 Jan 2005 00:33:22 +0100, Alex Martelli <[EMAIL PROTECTED]>
wrote:
By imposing transitivity, you're essentially asserting that, if a
programmer forgets to code and register an A -> C direct adapter, this
is never a problem, as
dapted-to interface, without facing
undetected degradation of information quality by that adapter being
invisibly, uncontrollably chained up with another -- no error message,
no nothing, no way to stop this -- just because a direct adapter wasn't
correctly written and registered. Just
On 2005 Jan 12, at 16:26, Guido van Rossum wrote:
...
[Alex]
I'm saying that if, by mistake, the programmer has NOT
registered the A->C adapter (which would be easily coded and work
perfectly), then thanks to transitivity, instead of a clear and simple
error message leading to i
101 - 200 of 364 matches
Mail list logo
