On 24 Apr, 2013, at 8:14, Ronald Oussoren wrote:
>
> On 24 Apr, 2013, at 1:32, "lukasz.langa" wrote:
>
>> http://hg.python.org/cpython/rev/9755036c81d0
>> changeset: 83510:9755036c81d0
>> branch: 3.3
>> parent: 83508:44d764238f0d
>> user:Łukasz Langa
>> date:Wed A
On 24 Apr, 2013, at 1:32, "lukasz.langa" wrote:
> http://hg.python.org/cpython/rev/9755036c81d0
> changeset: 83510:9755036c81d0
> branch: 3.3
> parent: 83508:44d764238f0d
> user:Łukasz Langa
> date:Wed Apr 24 01:29:26 2013 +0200
> summary:
> backported rev 79713 fro
On Tue, Apr 23, 2013 at 7:12 PM, R. David Murray wrote:
> On Wed, 24 Apr 2013 11:37:16 +1200, Greg Ewing
> wrote:
>> R. David Murray wrote:
>> > The first False looks correct to me, I would not expect an enum value to
>> > be an instance of the class that holds it as an attribute. The second
>>
Terry Jan Reedy writes:
> .transform should be explicit and always take two args, no implicit
> defaults, the 'from form' and the 'to' form. They can labelled by
> position in the natural order (from, to)
Not natural to escaped-from-C programmers, though. I hesitate to say
"make it keywor
Greg Ewing writes:
> Web developers might grumble about the need for an extra call,
> but they can no longer claim it would kill the performance of
> their web server.
Of course they can. There never was any performance measurement that
supported that claim in the first place. I don't see ho
R. David Murray writes:
> > I think you're completely missing my point here. The problem is that
> > in the cases I mention, what is encoded data and what is decoded data
> > can only be decided by asking the user.
>
> I think I understood that. I don't understand why that's a
> problem.
On Wed, 24 Apr 2013 11:37:16 +1200, Greg Ewing
wrote:
> R. David Murray wrote:
> > The first False looks correct to me, I would not expect an enum value to
> > be an instance of the class that holds it as an attribute. The second
> > certainly looks odd, but what does it even mean to have an ins
R. David Murray wrote:
The first False looks correct to me, I would not expect an enum value to
be an instance of the class that holds it as an attribute. The second
certainly looks odd, but what does it even mean to have an instance of
an Enum class?
This attitude baffles me. In most other la
Stephen J. Turnbull wrote:
By RFC specification, BASE64 is a
*textual* representation of arbitrary binary data. (Cf. URIs.) The
natural interpretation of .encode('base64') in that context would be
as a bytes-to-text encoder. However, ... In
practice, we invariably use an ASCII octet stream to
On 4/23/2013 11:58 AM, Guido van Rossum wrote:
> You seem to be mixing up classes and metaclasses.
I was trying to explain it in more plain terms, but maybe I made it even
more confusing.. Anyways, I agree with you that isinstance(Color.RED,
Color) should be True.
--
Scott Dial
sc...@scottdial.c
On 24 Apr 2013 01:25, "M.-A. Lemburg" wrote:
>
> On 23.04.2013 17:15, Barry Warsaw wrote:
> > On Apr 22, 2013, at 06:22 PM, Guido van Rossum wrote:
> >
> >>> You can ask the same question about all the other codecs. (And that
> >>> question has indeed been asked in the past.)
> >>
> >> Except for
On Apr 23, 2013, at 8:11 AM, Guido van Rossum wrote:
> I gotta say, I'm with Antoine here. It's pretty natural (also coming
> from other languages) to assume that the class used to define the
> enums is also the type of the enum values. Certainly this is how it
> works in Java and C++, and I woul
On 4/23/2013 12:49 PM, Stephen J. Turnbull wrote:
Which is an obnoxious API, since (1) you've now made it impossible to
use "transform" for
bytestring.transform(from='utf-8', to='iso-8859-1')
bytestring.transform(from='ulaw', to='mp3')
textstring.transform(from='rest', to='html')
On Wed, 24 Apr 2013 01:49:39 +0900, "Stephen J. Turnbull"
wrote:
> R. David Murray writes:
> > On Tue, 23 Apr 2013 22:29:33 +0900, "Stephen J. Turnbull"
> wrote:
> > > R. David Murray writes:
> > >
> > > > You transform *into* the encoding, and untransform *out* of the
> > > > encoding.
On Tue, Apr 23, 2013 at 9:04 AM, M.-A. Lemburg wrote:
> On 23.04.2013 17:47, Guido van Rossum wrote:
>> On Tue, Apr 23, 2013 at 8:22 AM, M.-A. Lemburg wrote:
>>> Just as reminder: we have the general purpose
>>> encode()/decode() functions in the codecs module:
>>>
>>> import codecs
>>> r13 = cod
R. David Murray writes:
> On Tue, 23 Apr 2013 22:29:33 +0900, "Stephen J. Turnbull"
> wrote:
> > R. David Murray writes:
> >
> > > You transform *into* the encoding, and untransform *out* of the
> > > encoding. Do you have an example where that would be ambiguous?
> >
> > In the byte
On 23.04.2013 17:47, Guido van Rossum wrote:
> On Tue, Apr 23, 2013 at 8:22 AM, M.-A. Lemburg wrote:
>> Just as reminder: we have the general purpose
>> encode()/decode() functions in the codecs module:
>>
>> import codecs
>> r13 = codecs.encode('hello world', 'rot-13')
>>
>> These interface direc
You seem to be mixing up classes and metaclasses.
On Tue, Apr 23, 2013 at 8:46 AM, Scott Dial
wrote:
> On 4/23/2013 10:53 AM, R. David Murray wrote:
>> Ah. I'd be looking for a bug every time I saw isinstance(value,
>> myEnumClass). A better class name for values and an API for
>> getting that
On Tue, 23 Apr 2013 08:44:21 -0700, Guido van Rossum wrote:
> On Tue, Apr 23, 2013 at 8:31 AM, R. David Murray
> wrote:
> > On Tue, 23 Apr 2013 08:11:06 -0700, Guido van Rossum
> > wrote:
> >> I gotta say, I'm with Antoine here. It's pretty natural (also coming
> >> from other languages) to as
On 4/23/2013 10:53 AM, R. David Murray wrote:
> Ah. I'd be looking for a bug every time I saw isinstance(value,
> myEnumClass). A better class name for values and an API for
> getting that class from the EnumClass would be nice, though.
> (So that you could write "isinstance(value, MyEnumClass.Va
On Tue, Apr 23, 2013 at 8:22 AM, M.-A. Lemburg wrote:
> Just as reminder: we have the general purpose
> encode()/decode() functions in the codecs module:
>
> import codecs
> r13 = codecs.encode('hello world', 'rot-13')
>
> These interface directly to the codec interfaces, without
> enforcing type
On Tue, Apr 23, 2013 at 8:31 AM, R. David Murray wrote:
> On Tue, 23 Apr 2013 08:11:06 -0700, Guido van Rossum wrote:
>> I gotta say, I'm with Antoine here. It's pretty natural (also coming
>> from other languages) to assume that the class used to define the
>> enums is also the type of the enum
On Tue, 23 Apr 2013 08:11:06 -0700, Guido van Rossum wrote:
> I gotta say, I'm with Antoine here. It's pretty natural (also coming
> from other languages) to assume that the class used to define the
> enums is also the type of the enum values. Certainly this is how it
> works in Java and C++, and
On 23.04.2013 17:15, Barry Warsaw wrote:
> On Apr 22, 2013, at 06:22 PM, Guido van Rossum wrote:
>
>>> You can ask the same question about all the other codecs. (And that
>>> question has indeed been asked in the past.)
>>
>> Except for rot13. :-)
>
> The fact that you can do this instead *is* a
Hello,I am writing some C extensions (using swig).A first extension (a python
module) which I'll call E1.I wrote a setup.py which works fine on all
platforms.On Windows 7 it creates a library which is a .pyd fileNow I want
to write a second C extension E2 that is calling some functions of E1.The
sa
Hello,
I am writing some C extensions (using swig).
A first extension (a python module) which I'll call E1.
I wrote a setup.py which works fine on all platforms.
On Windows 7 it creates a library which is a .pyd file
Now I want to write a second C extension E2 that is calling some functions
of E1
On Apr 22, 2013, at 06:22 PM, Guido van Rossum wrote:
>> You can ask the same question about all the other codecs. (And that
>> question has indeed been asked in the past.)
>
>Except for rot13. :-)
The fact that you can do this instead *is* a bit odd. ;)
from codecs import getencoder
encoder =
I gotta say, I'm with Antoine here. It's pretty natural (also coming
from other languages) to assume that the class used to define the
enums is also the type of the enum values. Certainly this is how it
works in Java and C++, and I would say it's the same in Pascal and
probably most other languages
On Apr 22, 2013, at 10:30 PM, Donald Stufft wrote:
>I may be dull, but it wasn't until I started using Python 3 that it really
>clicked in my head what encode/decode did exactly. In Python2 I just sort of
>sprinkled one or the other when there was errors until the pain stopped. I
>mostly attribute
Le Wed, 24 Apr 2013 00:22:40 +1000,
Nick Coghlan a écrit :
>
> Looking at the source
> (https://bazaar.launchpad.net/~barry/flufl.enum/trunk/view/head:/flufl/enum/_enum.py),
> I'm not seeing any fundamental technical issues with merging the Enum
> and EnumValue class definitions, and then using "
On Tue, 23 Apr 2013 16:33:02 +0200, Antoine Pitrou wrote:
> Le Tue, 23 Apr 2013 10:24:18 -0400,
> "R. David Murray" a écrit :
> > >
> > > I'm having a problem with the proposed implementation. I haven't
> > > found any mention of it, so apologies if this has already been
> > > discussed:
> > >
On Wed, Apr 24, 2013 at 12:16 AM, R. David Murray wrote:
> On Tue, 23 Apr 2013 22:29:33 +0900, "Stephen J. Turnbull"
> wrote:
>> R. David Murray writes:
>>
>> > You transform *into* the encoding, and untransform *out* of the
>> > encoding. Do you have an example where that would be ambiguous?
Le Tue, 23 Apr 2013 10:24:18 -0400,
"R. David Murray" a écrit :
> >
> > I'm having a problem with the proposed implementation. I haven't
> > found any mention of it, so apologies if this has already been
> > discussed:
> >
> > >>> from flufl.enum import *
> > >>> class C(Enum):
> > ... a = 1
>
On Tue, Apr 23, 2013 at 11:44 PM, Antoine Pitrou wrote:
> I'm having a problem with the proposed implementation. I haven't found
> any mention of it, so apologies if this has already been discussed:
>
from flufl.enum import *
class C(Enum):
> ... a = 1
> ... b = 2
> ...
C.a.__clas
On Tue, 23 Apr 2013 15:44:58 +0200, Antoine Pitrou wrote:
> Le Fri, 12 Apr 2013 05:55:00 -0700,
> Eli Bendersky a écrit :
> >
> > We're happy to present the revised PEP 435, collecting valuable
> > feedback from python-ideas discussions as well as in-person
> > discussions and decisions made du
On Tue, 23 Apr 2013 22:29:33 +0900, "Stephen J. Turnbull"
wrote:
> R. David Murray writes:
>
> > You transform *into* the encoding, and untransform *out* of the
> > encoding. Do you have an example where that would be ambiguous?
>
> In the bytes-to-bytes case, any pair of character encodings
Hello,
(sorry for the previous message attempt - my mouse pointer hit the send
button before I was finished with it)
Le Fri, 12 Apr 2013 05:55:00 -0700,
Eli Bendersky a écrit :
>
> We're happy to present the revised PEP 435, collecting valuable
> feedback from python-ideas discussions as well
Hello,
Le Fri, 12 Apr 2013 05:55:00 -0700,
Eli Bendersky a écrit :
>
> We're happy to present the revised PEP 435, collecting valuable
> feedback from python-ideas discussions as well as in-person
> discussions and decisions made during the latest PyCon language
> summit. We believe the proposa
Python-List (http://mail.python.org/mailman/listinfo/python-list) is the
better place for this kind of question; Python-Dev is for the development
of Python itself, not for development using Python.
When you built E1, it should have also built a ".lib" file in addition to
the ".pyd". It's the .lib
R. David Murray writes:
> You transform *into* the encoding, and untransform *out* of the
> encoding. Do you have an example where that would be ambiguous?
In the bytes-to-bytes case, any pair of character encodings (eg, UTF-8
and ISO-8859-15) would do. Or how about in text, ReST to HTML?
BA
Hello,
I am a researcher in Applied Math.
For my work I write a lot of code and right now I am moving to python.
I am writing some C extensions (using swig).
I wrote a first extension (a python module) which I'll call E1.
I wrote a setup.py which works fine on all platforms.
On Windows 7 it
41 matches
Mail list logo
