On Wed, Nov 25, 2009 at 16:41, Martijn Faassen faas...@startifact.com wrote:
As a final thought, I don't like having to import 'implements' from
zope.interface either. Since we're moving to Python 2.6 which supports
class decorators, I'd like to see something like this become possible:
Chris McDonough wrote:
Martijn Faassen wrote:
[snip]
So now that we've had some discussion and to exit the bikeshed phase,
let's see about getting some volunteers to work on this.
The goal here is to make interfaces disappear into the language as much
as possible.
I suggest we think to
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Are people okay with the proposed semantics?
+1.
Would people be okay with such an upgrade path? Any better ideas?
I would start issuign DeprecationWarnings (yes, I know I'm their worst
fan,
Adam GROSZER wrote:
I had a feeling that adapter lookup can be alone slowish with lots of
registrations.
We had a large project that was cut in half and the z3c.form UI, which
is rather heavily adaptation based got a boost after that.
Interesting. It'd be interesting to do some experiments
Chris McDonough wrote:
[snip]
It tries to address the following problem.
Currently people seem to get wrapped around the axle and confused by the
purpose of the ZCA, which currently implies at least two different things:
- Machinery to perform complex registrations and lookups using
Chris McDonough wrote:
Martijn Faassen wrote:
Hey,
Christian Theune wrote:
[snip]
Another option would be to provide a backwards-compatibility mode of our
code which can be switched on and off.
Your notion of bringing the component lookup mechanics closer to being a
language feature is
Summary of messages to the zope-tests list.
Period Fri Nov 27 12:00:00 2009 UTC to Sat Nov 28 12:00:00 2009 UTC.
There were 6 messages: 6 from Zope Tests.
Tests passed OK
---
Subject: OK : Zope-2.10 Python-2.4.6 : Linux
From: Zope Tests
Date: Fri Nov 27 20:38:38 EST 2009
URL:
On Sat, Nov 28, 2009 at 12:14 PM, Martijn Faassen
faas...@startifact.com wrote:
Adam GROSZER wrote:
I had a feeling that adapter lookup can be alone slowish with lots of
registrations.
We had a large project that was cut in half and the z3c.form UI, which
is rather heavily adaptation based
Am 27.11.2009, 15:57 Uhr, schrieb Chris Withers ch...@simplistix.co.uk:
Well, I don't think the difference between adapters and utilities is
important, but I can understand why some people find calling the
interface odd: it is when you think about it objectively.
I have to agree with this.
Charlie Clark wrote:
Am 27.11.2009, 15:57 Uhr, schrieb Chris Withers ch...@simplistix.co.uk:
Well, I don't think the difference between adapters and utilities is
important, but I can understand why some people find calling the
interface odd: it is when you think about it objectively.
I
Am 24.11.2009, 04:24 Uhr, schrieb Chris McDonough chr...@plope.com:
We've been handling some constructive criticisms from repoze.bfg
developers
with respect to verbosity resulting from use of unnamed utility
registrations
in a component architecture registry.
These criticisms, and our
Am 28.11.2009, 16:06 Uhr, schrieb Martijn Faassen faas...@startifact.com:
I have to agree with this. IFoo(myobject) is not intuitive. I know it
used
a lot because it's convenient shorthand but I've never read anywhere
that
interface classes are, in fact, callables. We certainly don't
On Sat, Nov 28, 2009 at 16:39, Charlie Clark
charlie.cl...@clark-consulting.eu wrote:
So adapters are reduced to type conversion?
That's what adapters are. They aren't reduced to it, it's what they
do. They adapt one object with one interface to have another
interface. That can indeed be seen as
Lennart Regebro wrote:
I have very much
come to appreciate the power of this delegation in, say, BrowserViews;
even if it did take me several months to understand the multiadapter
pattern!
I hear this a lot, so this is apparently something that is common to
take a while to grasp. Any ideas
Martijn Faassen wrote:
Chris McDonough wrote:
Martijn Faassen wrote:
[snip]
So now that we've had some discussion and to exit the bikeshed phase,
let's see about getting some volunteers to work on this.
The goal here is to make interfaces disappear into the language as much
as possible.
Am 28.11.2009, 16:55 Uhr, schrieb Lennart Regebro rege...@gmail.com:
That's what adapters are. They aren't reduced to it, it's what they
do. They adapt one object with one interface to have another
interface. That can indeed be seen as a type conversion.
I agree that that is probably the most
Martijn Faassen wrote:
I'd be in favor of an API based off calling the interface directly for
everything *if* we can come up with a backwards compatibility story somehow.
Just as a data point, I forgot to hook adapter_hook in BFG (and I still
haven't), which means that the IFoo() sugar
Charlie Clark wrote:
Am 24.11.2009, 04:24 Uhr, schrieb Chris McDonough chr...@plope.com:
We've been handling some constructive criticisms from repoze.bfg
developers
with respect to verbosity resulting from use of unnamed utility
registrations
in a component architecture registry.
On Sat, Nov 28, 2009 at 17:35, Charlie Clark
charlie.cl...@clark-consulting.eu wrote:
Am 28.11.2009, 16:55 Uhr, schrieb Lennart Regebro rege...@gmail.com:
That's what adapters are. They aren't reduced to it, it's what they
do. They adapt one object with one interface to have another
Just re-inforcing this I almost never do IFoo. adaption as I am almost
always using
multiadapters and utilities so I completely forget about the IFoo
adaption capability.
Which means I always just write getAdapter as well as it seems more
consistent to
from an api consumption point of view.
T
Hi,
The solution is very simple :)
Instead of sending the byte array like in the example, just encode it
as a string and send it in a variable using POST:
- base64 - this doesn;t works all the time... i don't know why
- bin to hex - works all the time
The server side code is like this:
img =
21 matches
Mail list logo
