Re: [Python-Dev] [Python-checkins] cpython (3.3): backported rev 79713 from 3.4, test_recursion_limit skipped for -O0
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 Apr 24 01:29:26 2013 +0200 >> summary: >> backported rev 79713 from 3.4, test_recursion_limit skipped for -O0 >> >> files: >> Lib/test/test_threading.py | 3 ++- >> 1 files changed, 2 insertions(+), 1 deletions(-) >> >> >> diff --git a/Lib/test/test_threading.py b/Lib/test/test_threading.py >> --- a/Lib/test/test_threading.py >> +++ b/Lib/test/test_threading.py >> @@ -754,7 +754,8 @@ >>lock = threading.Lock() >>self.assertRaises(RuntimeError, lock.release) >> >> -@unittest.skipUnless(sys.platform == 'darwin', 'test macosx problem') >> +@unittest.skipUnless(sys.platform == 'darwin' and >> test.support.python_is_optimized(), >> + 'test macosx problem') > > Wouldn't it be better to just fix the issue? thread_pthread already sets an > explicit stack size on OSX, but that value is appearently too small. In particular, this patch appears to fix the crash that's the reason for disabling the test: diff --git a/Python/thread_pthread.h b/Python/thread_pthread.h --- a/Python/thread_pthread.h +++ b/Python/thread_pthread.h @@ -28,7 +28,7 @@ */ #if defined(__APPLE__) && defined(THREAD_STACK_SIZE) && THREAD_STACK_SIZE == 0 #undef THREAD_STACK_SIZE -#define THREAD_STACK_SIZE 0x50 +#define THREAD_STACK_SIZE 0x55 #endif #if defined(__FreeBSD__) && defined(THREAD_STACK_SIZE) && THREAD_STACK_SIZE == 0 #undef THREAD_STACK_SIZE Without this patch test_recursion_limit fails due to a crash, with the patch the test passes (debug build, x86_64, OSX 10.8.3). Ronald ___ 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
Re: [Python-Dev] [Python-checkins] cpython (3.3): backported rev 79713 from 3.4, test_recursion_limit skipped for -O0
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 from 3.4, test_recursion_limit skipped for -O0 > > files: > Lib/test/test_threading.py | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > > diff --git a/Lib/test/test_threading.py b/Lib/test/test_threading.py > --- a/Lib/test/test_threading.py > +++ b/Lib/test/test_threading.py > @@ -754,7 +754,8 @@ > lock = threading.Lock() > self.assertRaises(RuntimeError, lock.release) > > -@unittest.skipUnless(sys.platform == 'darwin', 'test macosx problem') > +@unittest.skipUnless(sys.platform == 'darwin' and > test.support.python_is_optimized(), > + 'test macosx problem') Wouldn't it be better to just fix the issue? thread_pthread already sets an explicit stack size on OSX, but that value is appearently too small. Ronald ___ 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
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
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 >> > certainly looks odd, but what does it even mean to have an instance of >> > an Enum class? >> >> This attitude baffles me. In most other languages having a >> notion of an enum, when you define an enum, you're defining >> a type. The name of the enum is the name of the type, and >> its values are instances of that type. >> >> Why should our enums be any different? > > Obviously they don't need to be, since people have discussed how to > implement this. > > But I am primarily a Python programmer, so my intuition is based on my > Python experience, not on what other languages do. > > Given: > > MyEnum(Enum): >a = 1 >b = 2 > > I understood that 'a' and 'b' are class attributes, where the int value > had been transformed into instances of a (separate) value class rather > than being ints. The fact that there was a specific value class > had been discussed. > > If 'a' is now an instance of MyEnum, then I would expect that: > > MyEnum.a.b > > would be valid (b being an attribute of the MyEnum class which should > therefore be accessible from an instance of that class). That seems > a bit odd, and based on my Python-only mindset, I saw no particular > reason why an enum value *should* be instance of the enum class, since > it would lead to that oddity. (Well, I'm not sure I was concious of > that *particular* oddity, but in general it seemed like an odd thing to > have class attributes of a class be instances of that class when the set > of class attributes was the most important thing about that class...). > It seemed more natural for the values to be instances of a separate > value class. > > Now, given that I was viewing the Enum as being a collection of attributes > whose values were instances of a different class, what would it mean > to create an instance of the Enum class itself? You'd have an instance > with access to those class attributes...but the getitem wouldn't work, > because that's on the metaclass. You'd really want the Enum class to > be a singleton...the important thing was that it was an instance of the > metaclass, its instances would be pretty useless. > > I don't have any *problem* with enum values being instances of the class. > If you make the attribute values instances of the enum class, then > yes instances of enum class have a meaning. And then having attributes > of the class be instances of the class makes perfect sense in > hindsight. > > It's just not where *my* Python-only intuition, or my understanding of > the discussion, led me. > > I feel like I'm revealing my ignorance or stupidity here, but what the > heck, that's what was going through my brain and I might as well own up > to it :). I'm not too worried. Clearly the Enum base class is magic, because, contrary to the behavior of regular class definitions, MyEnum.a is *not* just the integer 1 (even if it compares == to 1). At that point we may as well accept that the entire construct is magic, and the only consequences we can reason about are those that are documented as consequences of using this particular kind of magic. I'm not sure that we can implement a hack to prevent MyEnum.a.b from being an alias for MyEnum.b, but even if we cannot prevent that, I don't think we need to worry about it. (However, I suspect we can override __getattr__ to prevent this if it is considered too unsavory.) -- --Guido van Rossum (python.org/~guido) ___ 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
Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?
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 keywords-only", but using keywords should be *strongly*
encouraged.
> str.transform would always be unicode to unicode and bytes.transform
> always bytes to bytes.
Which leaves the salient cases (MIME content transfer encodings) out
in the cold, although I guess
string.encode('ascii').transform(from='base64', to='bytes')
isn't too horrible.
___
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
Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?
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 how PEP 393 makes a difference to them. The real problem for them is that conceptually they think ASCII in byte form *is* text, and they want to do text processing on it. They'll use any flimsy excuse to avoid a transform to str, because it's just unbearably ugly given their givens. I have sympathy for their position, I just (even today) think it's the wrong thing for Python. However, I've long since been overruled, and I have no evidence to justify saying "I told you so". ___ 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
Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?
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.
It's a problem because in that case it's hard for users to remember
the directionality of the codec based only on a single name; the API
needs to indicate what is being transformed to what else.
> I've been trying to explain what I thought the transform/untransform
> proposal was: a minimalist extension of the encode/decode semantic
> (under a different name) so that functionality that was lost from
> Python2 encode/decode could be restored to Python3 in a reasonably
> understandable way.
I think that the intention of the proposal is reasonably
understandable, and reasonable. I just don't think the API proposed
is understandable, and therefore it's not reasonable.
> People (at least you and Nick, and maybe Guido) seem to be more
> interested in a more general/powerful mechanism. I'm fine with
> that :)
I can't speak to the opinions of people who actually know about
language design. For myself, I'm sympathetic to the proposal of a
specific API limited to cases where the directionality is clear as a
generality. I just don't think the "transform" proposal helps much,
partly because the actual applications are few, and partly because
"transform" is more ambiguous (to be unambiguous in English, you need
both the direct object ("from media type") and the indirect object
("to media type") specified. It is quite possible to say "transform
encoded text to raw text" or similar. At least for me, "encode
transformed text to raw text" raises a WTFAssertion.
I know that I've experienced worlds of pain in the character coding
sphere from Emacs APIs and UIs that don't indicate directionality
clearly. This is very delicate; GNU Emacs had an ugly bug that
regressed multiple times over more than a decade merely because they
exposed the internal representation of text to Lisp. XEmacs has never
experienced that bug (to be precise, the presence of that kind of bug
resulted in an immediate assertion, so it was eliminated early in
development). Surprisingly to me, the fact that XEmacs uses the
internal representation of *text* to also represent "byte streams"
(with bytes of variable width!) has never caused me confusion. It
does cause others confusion, though, so although the XEmacs model of
text is easier to work with than Emacs's, I tend to think Python 3's
(which never confounds text with bytes) is better.
I suspect that delicacy extends to non-character transformations, so I
am pretty demanding about proposals in this area. Specifically I
insist on EIBTI and TOOWTDI.
___
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
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
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 instance of > > an Enum class? > > This attitude baffles me. In most other languages having a > notion of an enum, when you define an enum, you're defining > a type. The name of the enum is the name of the type, and > its values are instances of that type. > > Why should our enums be any different? Obviously they don't need to be, since people have discussed how to implement this. But I am primarily a Python programmer, so my intuition is based on my Python experience, not on what other languages do. Given: MyEnum(Enum): a = 1 b = 2 I understood that 'a' and 'b' are class attributes, where the int value had been transformed into instances of a (separate) value class rather than being ints. The fact that there was a specific value class had been discussed. If 'a' is now an instance of MyEnum, then I would expect that: MyEnum.a.b would be valid (b being an attribute of the MyEnum class which should therefore be accessible from an instance of that class). That seems a bit odd, and based on my Python-only mindset, I saw no particular reason why an enum value *should* be instance of the enum class, since it would lead to that oddity. (Well, I'm not sure I was concious of that *particular* oddity, but in general it seemed like an odd thing to have class attributes of a class be instances of that class when the set of class attributes was the most important thing about that class...). It seemed more natural for the values to be instances of a separate value class. Now, given that I was viewing the Enum as being a collection of attributes whose values were instances of a different class, what would it mean to create an instance of the Enum class itself? You'd have an instance with access to those class attributes...but the getitem wouldn't work, because that's on the metaclass. You'd really want the Enum class to be a singleton...the important thing was that it was an instance of the metaclass, its instances would be pretty useless. I don't have any *problem* with enum values being instances of the class. If you make the attribute values instances of the enum class, then yes instances of enum class have a meaning. And then having attributes of the class be instances of the class makes perfect sense in hindsight. It's just not where *my* Python-only intuition, or my understanding of the discussion, led me. I feel like I'm revealing my ignorance or stupidity here, but what the heck, that's what was going through my brain and I might as well own up to it :). --David ___ 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
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
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 languages having a notion of an enum, when you define an enum, you're defining a type. The name of the enum is the name of the type, and its values are instances of that type. Why should our enums be any different? -- Greg ___ 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
Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?
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 carry BASE64-
encoded data.
As an aside, if we'd had the flexible string representation sooner,
this needn't have been such a big problem. With it, the base64
encoder could return a unicode string with 8-bit representation,
which could then be turned into an ascii byte string with
negligible overhead.
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.
--
Greg
___
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
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
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.com ___ 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
Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?
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 rot13. :-)
> >
> > The fact that you can do this instead *is* a bit odd. ;)
> >
> > from codecs import getencoder
> > encoder = getencoder('rot-13')
> > r13 = encoder('hello world')[0]
>
> 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 restrictions. The codec defines the supported
> input and output types.
If we already have those, why aren't they documented? If they exist, they
should be the first thing in the codecs module docs and the porting guide
should list them as the replacement for the method versions when using
encodings that aren't directly related to the text model, or when the input
buffer for decoding isn't a bytes or bytearray object.
Regards,
Nick.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Apr 23 2013)
> >>> Python Projects, Consulting and Support ... http://www.egenix.com/
> >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/
> >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
>
> 2013-04-17: Released eGenix mx Base 3.2.6 ... http://egenix.com/go43
>
> : Try our mxODBC.Connect Python Database Interface for free ! ::
>
>eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>Registered at Amtsgericht Duesseldorf: HRB 46611
>http://www.egenix.com/company/contact/
> ___
> 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/ncoghlan%40gmail.com
___
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
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
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 would say it's the same in Pascal and > probably most other languages. Furthermore, you could define methods/fields on enum values, like Java's enums. E.g.: Errno.EBADF.strerror() -> 'Bad file descriptor' Easily adapt to additional fields: class Protocol(Enum): HOPOPT = 0, "IPv6 Hop-by-Hop Option" ICMP = 1, "Internet Control Message" IGMP = 2, "Internet Group Management" @property def value(self): return self._value[0] @property def description(self): return self._value[1] -- Philip Jenvey ___ 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
Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?
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') without confusion, and (2) the whole world is going to wonder why you don't use .encode and .decode instead of .transform and .untransform. I think the unambiguous solution is to get rid of the notion of 'untransform' (which only means 'transform in the other direction'), since it requires and presumes an asymmetry that is not always present. It it precisely the lack of asymmetry in examples like the above that makes the transform/untransform pair ambiguous as to which is which. .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) or by keyword, as in your examples. For text, the plain undifferentiated form which one might think of as default could be called 'text' and that for bytes 'bytes' (as you suggest) or 'ascii' as appropriate. str.transform would always be unicode to unicode and bytes.transform always bytes to bytes. ___ 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
Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?
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. 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?
> >
> > If I write:
> >
> > bytestring.transform('ISO-8859-15')
> >
> > that would indeed be ambiguous, but only because I haven't named the
> > source encoding of the bytestring. So the above is obviously
> > nonsense, and the easiest "fix" is to have the things that are currently
> > bytes-to-text or text-to-bytes character set transformations *only*
> > work with encode/decode, and not transform/untransform.
>
> 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.
(But see below.)
> > Given this, the possible valid transformations would be:
> >
> > bytestring.transform('base64')
> > bytesstring.untransform('base64')
> > string.untransform('base64')
>
> 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')
>
> without confusion, and (2) the whole world is going to wonder why you
> don't use .encode and .decode instead of .transform and .untransform.
I've been trying to explain what I thought the transform/untransform
proposal was: a minimalist extension of the encode/decode semantic
(under a different name) so that functionality that was lost from
Python2 encode/decode could be restored to Python3 in a reasonably
understandable way. This would be a *limited* convenience function,
just as encode/decode are limited convenience functions with respect to
the full power of the codecs module.
I myself don't have any real investment in the proposal, or I would
have long since tried to push the tracker issue forward.
People (at least you and Nick, and maybe Guido) seem to be more interested
in a more general/powerful mechanism. I'm fine with that :)
--David
___
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
Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?
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 = codecs.encode('hello world', 'rot-13')
>>>
>>> These interface directly to the codec interfaces, without
>>> enforcing type restrictions. The codec defines the supported
>>> input and output types.
>>
>> As an implementation mechanism I see nothing wrong with this. I hope
>> the codecs module lets you introspect the input and output types of a
>> codec given by name?
>
> At the moment there is no standard interface to access supported
> input and output types... but then: regular Python functions or
> methods also don't provide such functionality, so no surprise
> there ;-)
Not quite the same though. Each function has its own unique behavior.
But codecs support a standard interface, *except* that the input and
output types sometimes vary.
> It's mostly a matter of specifying the supported type
> combinations in the codec documentation.
>
> BTW: What would be a use case where you'd want to
> programmatically access such information before calling
> the codec ?
As you know, in Python 3, most code working with bytes doesn't also
work with strings, and vice versa (except for a few cases where we've
gone out of our way to write polymorphic code -- but users rarely do
so, and any time you use a string or bytes literal you basically limit
yourself to that type).
Suppose I write a command-line utility that reads a file, runs it
through a codec, and writes the result to another file. Suppose the
name of the codec is a command-line argument (as well as the
filenames). I need to know whether to open the files in text or binary
mode based on the name of the codec.
--
--Guido van Rossum (python.org/~guido)
___
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
Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?
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 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?
>
> If I write:
>
> bytestring.transform('ISO-8859-15')
>
> that would indeed be ambiguous, but only because I haven't named the
> source encoding of the bytestring. So the above is obviously
> nonsense, and the easiest "fix" is to have the things that are currently
> bytes-to-text or text-to-bytes character set transformations *only*
> work with encode/decode, and not transform/untransform.
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 believe that after much discussion we have settled on these
> transformations (in their respective modules) accepting either bytes
> or strings as input for decoding, only bytes as input for encoding,
> and *always* producing bytes as output.
Which, of course, is quite broken from the point of view of the RFC!
Of course, the RFC be damned[1], for the purposes of the Python
stdlib, the specific codecs used for Content-Transfer-Encoding have a
clear intuitive directionality, and their encoding methods should turn
bytes into bytes (and str or bytes into bytes on decoding).
Nevertheless, it's not TOOWTDI, it's a careful compromise.
> Given this, the possible valid transformations would be:
>
> bytestring.transform('base64')
> bytesstring.untransform('base64')
> string.untransform('base64')
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')
without confusion, and (2) the whole world is going to wonder why you
don't use .encode and .decode instead of .transform and .untransform.
The idea in the examples is that we could generalize the codec
registry to look up codecs by pairs of media-types. I'm not sure this
makes sense ... much of the codec API presumes a stream, especially
the incremental methods. But many MIME media types are streams only
because they're serializations, incremental en/decoding is nonsense.
So I suppose I would want to write
bytestring.transform(from='octet-stream', to='BASE64')
for this hypothetical API. (I suspect that in practice the
'application/octet-stream' media type would be spelled 'bytes', of
course.) This kind of API could be used to improve the security of
composition of transforms. In the case of BASE64, it would make sense
to match anything at all as the other type (as long as it's
represented in Python by a bytes object). So it would be possible to
do
object = bytestring.transform(from='BASE64', to='PNG')
giving object a media_type attribute such that
object.decode('iso-8859-1')
would fail. (This would require changes to the charset codecs, to pay
heed to the media_type attribute, so it's not immediately feasible.)
> and all would produce a byte string. That byte string would be in
> base64 for the first one, and a decoded binary string for the second two.
>
> Given our existing API, I don't think we want
>
> string.encode('base64')
>
> to work (taking an ascii-only unicode string and returning bytes),
No, we don't, but for reasons that have little to do with "ASCII-only".
The problem with supporting that idiom is that *people can't read
strs* [in the Python 3 internal representation] -- they can only read
a str that has been encoded implicitly into the PYTHONIOENCODING or
explicitly to an explicitly requested encoding. So the usage above is
clearly ambiguous. Even if it is ASCII-only, in theory the user could
want EBCDIC.
> If you do transform('base64') on a bytestring already encoded as
> base64 you get a double encoding, yes. I don't see that it is our
> responsibility to try to protect you from this mistake. The module
> functions certainly don't.
>
> Given that, is there anything ambiguous about the proposed API?
Not for BASE64. But what's so special about BASE64 that it deserves a
new method name for the same old idiom, using a word that's an obvious
candidate for naming a more general idiom?
> (Note: if you would like to argue that, eg, base64.b64encode or
> binascii.b2a_base64 should return a string, it is too late for that
> argument for backward compatibility reasons.)
Even if it weren't too late, the byte-shoveling lobby is way too
strong; that's not a winnable agument.
> When I asked about ambiguous cases, I was asking for cases where
> the meaning of "transform('somecodec')" was ambiguo
Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?
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 directly to the codec interfaces, without
>> enforcing type restrictions. The codec defines the supported
>> input and output types.
>
> As an implementation mechanism I see nothing wrong with this. I hope
> the codecs module lets you introspect the input and output types of a
> codec given by name?
At the moment there is no standard interface to access supported
input and output types... but then: regular Python functions or
methods also don't provide such functionality, so no surprise
there ;-)
It's mostly a matter of specifying the supported type
combinations in the codec documentation.
BTW: What would be a use case where you'd want to
programmatically access such information before calling
the codec ?
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Apr 23 2013)
>>> Python Projects, Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
2013-04-17: Released eGenix mx Base 3.2.6 ... http://egenix.com/go43
: Try our mxODBC.Connect Python Database Interface for free ! ::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
___
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
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
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 class from the EnumClass would be nice, though. >> (So that you could write "isinstance(value, MyEnumClass.ValueClass)", >> say.) > > Reading what you have wrote, it seems that the issue is whether you > consider an instance of Enum a "thing" or a "class of things". If you > think of it as a "thing", then "C" is a object that has attributes for > other "things" that are not like "C". However, if you think of "C" as a > "class of things", then "C" having attributes that are instances of it's > type is completely natural. > > Fundamentally, the question is whether an instance of Enum is a new type > or an instance. And for me, it's a new type and I expect enum values to > be instance of that type. > > -Scott > > -- > Scott Dial > sc...@scottdial.com > ___ > 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/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ 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
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
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 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. > > > > Well, I guess I can wrap my head around it :) An Enum is an odd duck > > anyway, which I suppose is one of the things that makes it worth adding. > > Sorry, you're being to literary/poetic. I can't tell what you meant by > this response. I was alluding to the fact that in Python we usually work with instances of classes (not always, I know, but still...), but with Enum we are really using the class as a first level object. Given that, breaking my (questionable?) intuition about isinstance should not be unexpected. And by that last phrase I meant to refer to the fact that getting this right is obviously non-trivial, which is one of the things that makes it worth adding as a Python feature. --David ___ 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
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
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.ValueClass)", > say.) Reading what you have wrote, it seems that the issue is whether you consider an instance of Enum a "thing" or a "class of things". If you think of it as a "thing", then "C" is a object that has attributes for other "things" that are not like "C". However, if you think of "C" as a "class of things", then "C" having attributes that are instances of it's type is completely natural. Fundamentally, the question is whether an instance of Enum is a new type or an instance. And for me, it's a new type and I expect enum values to be instance of that type. -Scott -- Scott Dial sc...@scottdial.com ___ 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
Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?
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 restrictions. The codec defines the supported
> input and output types.
As an implementation mechanism I see nothing wrong with this. I hope
the codecs module lets you introspect the input and output types of a
codec given by name?
--
--Guido van Rossum (python.org/~guido)
___
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
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
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 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. > > Well, I guess I can wrap my head around it :) An Enum is an odd duck > anyway, which I suppose is one of the things that makes it worth adding. Sorry, you're being to literary/poetic. I can't tell what you meant by this response. -- --Guido van Rossum (python.org/~guido) ___ 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
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
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 I would say it's the same in Pascal and > probably most other languages. Well, I guess I can wrap my head around it :) An Enum is an odd duck anyway, which I suppose is one of the things that makes it worth adding. --David ___ 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
Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?
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 bit odd. ;)
>
> from codecs import getencoder
> encoder = getencoder('rot-13')
> r13 = encoder('hello world')[0]
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 restrictions. The codec defines the supported
input and output types.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Apr 23 2013)
>>> Python Projects, Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
2013-04-17: Released eGenix mx Base 3.2.6 ... http://egenix.com/go43
: Try our mxODBC.Connect Python Database Interface for free ! ::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
___
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
[Python-Dev] distutils win32 multiple extensions
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 same kind of setup.py works fine on all platforms but Windows where it says (during the link) that the function sof E1 that are called by E2 are unreferenced.I am clearly not a Windows pro ... I am using mingw32 on Windows.Surfing the web, I understood that shared libraries work differently on windows than on other platforms. And that I should1- export the symbols (i.e., the functions) of E1 when I build E1. In the distutils.Extension this seems to be done using argument export_symbols=[list of symbols to export]Now I have one problem : each time I specify in this list the name of a function in E1 it says that it doesn't know this symbolWhat am I doing wrong here, is there a special syntax ?2- Now in the setup.py of E2 how do I declare that I want to use the E1 shared lib.? Is the information on the exported symbol of E1 in the .pyd file or in the .def file ?I tried to specify the .pyd library in the arguments of the distutils.Extension but I have the feeling that's not the right thing to do (I have the feeling the .pyd is not the right file to point to)Not mentioning the problem specifying the path of the library with runtime_library_dirs ... which does not seem to work at all.Is there a simple way to do what I want to do ?I did not find anything on the web explaining clearly what to do ...I am really really stuckI would appreciate any kind of help Emmanuel -- View this message in context: http://python.6.x6.nabble.com/distutils-win32-multiple-extensions-tp5015137.html Sent from the Python - python-dev mailing list archive at Nabble.com.___ 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
[Python-Dev] distutils win32 multiple extensions
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. The same kind of setup.py works fine on all platforms but Windows where it says (during the link) that the function sof E1 that are called by E2 are unreferenced. I am clearly not a Windows pro ... I am using mingw32 on Windows. Surfing the web, I understood that shared libraries work differently on windows than on other platforms. And that I should 1- export the symbols (i.e., the functions) of E1 when I build E1. In the distutils.Extension this seems to be done using argument export_symbols=[list of symbols to export] Now I have one problem : each time I specify in this list the name of a function in E1 it says that it doesn't know this symbol What am I doing wrong here, is there a special syntax ? 2- Now in the setup.py of E2 how do I declare that I want to use the E1 shared lib.? Is the information on the exported symbol of E1 in the .pyd file or in the .def file ? I tried to specify the .pyd library in the arguments of the distutils.Extension but I have the feeling that's not the right thing to do (I have the feeling the .pyd is not the right file to point to) Not mentioning the problem specifying the path of the library with runtime_library_dirs ... which does not seem to work at all. Is there a simple way to do what I want to do ? I did not find anything on the web explaining clearly what to do ... I am really really stuck I would appreciate any kind of help Emmanuel -- View this message in context: http://python.6.x6.nabble.com/distutils-win32-multiple-extensions-tp5015138.html Sent from the Python - python-dev mailing list archive at Nabble.com. ___ 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
Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?
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 = getencoder('rot-13')
r13 = encoder('hello world')[0]
-Barry
___
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
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
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.
This doesn't seem to matter much today, but various people are
thinking about adding optional type annotations to Python code (use
cases include hints for liters and better suggestions for IDEs). What
would be more natural than being able to write
class Color(Enum):
RED = 1
WHITE = 2
BLUE = 3
ORANGE = 4
class Bikeshed:
def paint(self, hue: Color, opacity: int):
...
It would be awkward if the 'how' parameter had to be annotated with
Color.ValueClass, or if the type checkers had to learn to imply
.ValueClass if an attribute was labeled with an Enum type. Enums just
aren't special enough.
I find the docstring issue secondary.
--Guido
On Tue, Apr 23, 2013 at 7:57 AM, Antoine Pitrou wrote:
> 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 "cls" where the
>> metaclass code currently uses "cls.__value_factory__" (even for the
>> backwards compatible variant, the 2v3 metaclass issue isn't a problem,
>> you can just define a _BaseEnum class with the right metaclass using
>> the 2 & 3 compatible notation and inherit from that in a normal class
>> definition)
>>
>> However, there's one non-technical aspect of such a merger which does
>> concern me, which is the fact that you would lose the distinct
>> docstrings for the class and the values:
>
> You can work it around by making __doc__ a descriptor that behaves
> differently when called on a class or an instance. There is a slight
> metaclass complication because __doc__ is not writable on a class (but
> I suppose enums are already using a metaclass, so it's not much of an
> issue):
>
>
> class docwrapper:
> def __init__(self, class_doc, instance_doc_func):
> self.class_doc = class_doc
> self.instance_doc_func = instance_doc_func
>
> def __get__(self, instance, owner):
> if instance is None:
> return self.class_doc
> else:
> return self.instance_doc_func(instance)
>
> def instancedocwrapper(instance_doc_func):
> class metaclass(type):
> def __new__(meta, name, bases, dct):
> dct['__doc__'] = docwrapper(dct['__doc__'],
> instance_doc_func)
> return type.__new__(meta, name, bases, dct)
> return metaclass
>
> class D(metaclass=instancedocwrapper(
>lambda self: "My instance:{}".format(self.x))):
> """My beautiful, documented class."""
> def __init__(self, x):
> self.x = x
>
> class E(D):
> """My magnificent subclass."""
>
> print("class doc:", D.__doc__)
> print("subclass doc:", E.__doc__)
> print("instance doc:", E(5).__doc__)
>
>
> Note that the builtin help() function always displays the class's
> __doc__, even when called on an instance which has its own __doc__.
>
> Regards
>
> Antoine.
>
>
> ___
> 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/guido%40python.org
--
--Guido van Rossum (python.org/~guido)
___
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
Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?
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 this to str.decode and bytes.encode not existing. This is a key observation. It's also now much easier to *explain* what's going on and recommend correct code in Python 3, so overall it's a win. That's not to downplay the inconvenience of not being able to easily do bytes->bytes or str->str transformations as easily as was possible in Python 2. I've not thought about it much, but placing those types of transformations on a different set of functions (methods or builtins) seems like the right direction. IOW, don't mess with encode/decode. -Barry signature.asc Description: PGP signature ___ 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
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
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 "cls" where the
> metaclass code currently uses "cls.__value_factory__" (even for the
> backwards compatible variant, the 2v3 metaclass issue isn't a problem,
> you can just define a _BaseEnum class with the right metaclass using
> the 2 & 3 compatible notation and inherit from that in a normal class
> definition)
>
> However, there's one non-technical aspect of such a merger which does
> concern me, which is the fact that you would lose the distinct
> docstrings for the class and the values:
You can work it around by making __doc__ a descriptor that behaves
differently when called on a class or an instance. There is a slight
metaclass complication because __doc__ is not writable on a class (but
I suppose enums are already using a metaclass, so it's not much of an
issue):
class docwrapper:
def __init__(self, class_doc, instance_doc_func):
self.class_doc = class_doc
self.instance_doc_func = instance_doc_func
def __get__(self, instance, owner):
if instance is None:
return self.class_doc
else:
return self.instance_doc_func(instance)
def instancedocwrapper(instance_doc_func):
class metaclass(type):
def __new__(meta, name, bases, dct):
dct['__doc__'] = docwrapper(dct['__doc__'],
instance_doc_func)
return type.__new__(meta, name, bases, dct)
return metaclass
class D(metaclass=instancedocwrapper(
lambda self: "My instance:{}".format(self.x))):
"""My beautiful, documented class."""
def __init__(self, x):
self.x = x
class E(D):
"""My magnificent subclass."""
print("class doc:", D.__doc__)
print("subclass doc:", E.__doc__)
print("instance doc:", E(5).__doc__)
Note that the builtin help() function always displays the class's
__doc__, even when called on an instance which has its own __doc__.
Regards
Antoine.
___
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
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
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: > > > > > > >>> from flufl.enum import * > > > >>> class C(Enum): > > > ... a = 1 > > > ... b = 2 > > > ... > > > >>> C.a.__class__ > > > > > > >>> isinstance(C.a, C) > > > False > > > >>> isinstance(C(1), C) > > > False > > > > > > It would really be better if instances were actual instances of the > > > class, IMO. > > > > 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? > > Perhaps I should have added some context: > > >>> class C(Enum): > ... a = 1 > ... b = 2 > ... > >>> C(1) > > >>> C[1] > > > It is simply the same as a __getattr__ call. > > That said, I don't see why it wouldn't make sense for an enum value to > be an instance of that class. It can be useful to write > `isinstance(value, MyEnumClass)`. Also, any debug facility which has a > preference for writing out class names would produce a better output > than the generic "EnumValue". 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.ValueClass)", say.) --David ___ 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
Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?
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?
>>
>> 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?
>
> If I write:
>
> bytestring.transform('ISO-8859-15')
>
> that would indeed be ambiguous, but only because I haven't named the
> source encoding of the bytestring. So the above is obviously
> nonsense, and the easiest "fix" is to have the things that are currently
> bytes-to-text or text-to-bytes character set transformations *only*
> work with encode/decode, and not transform/untransform.
And that's where it all falls down - to make that work, you need to
engineer a complex system into the codecs module to say "this codec
can be used with that API, but not with this one". I designed such a
beast in http://bugs.python.org/issue7475 and I now think it's a *bad
idea*.
By contrast, the convenience function approach dispenses with all
that, and simply says:
1. If you just want to deal with text encodings, use str.encode (which
always produces bytes), along with bytes.decode and bytearray.decode
(which always produce str)
2. If you want to use arbitrary codecs without any additional type
constraints, do "from codecs import encode, decode"
I think there's value in hiding the arbitrary codec support behind an
import barrier (as they definitely have potential to be an attractive
nuisance that makes it harder to grasp the nature of Unicode and text
encodings, particularly for those coming from Python 2.x), but I'm not
hugely opposed to providing them as builtins either.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
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
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
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 > > ... b = 2 > > ... > > >>> C.a.__class__ > > > > >>> isinstance(C.a, C) > > False > > >>> isinstance(C(1), C) > > False > > > > It would really be better if instances were actual instances of the > > class, IMO. > > 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? Perhaps I should have added some context: >>> class C(Enum): ... a = 1 ... b = 2 ... >>> C(1) >>> C[1] It is simply the same as a __getattr__ call. That said, I don't see why it wouldn't make sense for an enum value to be an instance of that class. It can be useful to write `isinstance(value, MyEnumClass)`. Also, any debug facility which has a preference for writing out class names would produce a better output than the generic "EnumValue". Regards Antoine. ___ 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
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
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.__class__
>
isinstance(C.a, C)
> False
isinstance(C(1), C)
> False
>
>
> It would really be better if instances were actual instances of the
> class, IMO.
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 "cls" where the
metaclass code currently uses "cls.__value_factory__" (even for the
backwards compatible variant, the 2v3 metaclass issue isn't a problem,
you can just define a _BaseEnum class with the right metaclass using
the 2 & 3 compatible notation and inherit from that in a normal class
definition)
However, there's one non-technical aspect of such a merger which does
concern me, which is the fact that you would lose the distinct
docstrings for the class and the values:
>>> class C(flufl.enum.Enum):
... "My enum"
... a = 1
...
>>> print(C.__doc__)
My enum
>>> print(type(C.a).__doc__)
Class to represent an enumeration value.
EnumValue('Color', 'red', 12) prints as 'Color.red' and can be converted
to the integer 12.
So I'm not sure the PEP has made the wrong choice here, but I agree
the point is at least worth mentioning.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
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
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
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 during the latest PyCon language > > summit. We believe the proposal is now better than the original one, > > providing both a wider set of features and more convenient ways to > > use those features. > > 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.__class__ > > >>> isinstance(C.a, C) > False > >>> isinstance(C(1), C) > False > > It would really be better if instances were actual instances of the > class, IMO. 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? --David ___ 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
Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?
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 (eg, UTF-8
> and ISO-8859-15) would do. Or how about in text, ReST to HTML?
If I write:
bytestring.transform('ISO-8859-15')
that would indeed be ambiguous, but only because I haven't named the
source encoding of the bytestring. So the above is obviously
nonsense, and the easiest "fix" is to have the things that are currently
bytes-to-text or text-to-bytes character set transformations *only*
work with encode/decode, and not transform/untransform.
> BASE64 itself is ambiguous. 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, this has several problems. In
> practice, we invariably use an ASCII octet stream to carry BASE64-
> encoded data. So web developers would almost certainly expect a
> bytes-to-bytes encoder. Such a bytes-to-bytes encoder can't be
> duck-typed. Double-encoding bugs wouldn't be detected until the
> stream arrives at the user. And the RFC-based signature of
> .encode('base64') as bytes-to-text is precisely opposite to that of
> .encode('utf-8') (text-to-bytes).
I believe that after much discussion we have settled on these
transformations (in their respective modules) accepting either bytes
or strings as input for decoding, only bytes as input for encoding,
and *always* producing bytes as output. (Note that the base64 docs need
some clarification about this.)
Given this, the possible valid transformations would be:
bytestring.transform('base64')
bytesstring.untransform('base64')
string.untransform('base64')
and all would produce a byte string. That byte string would be in
base64 for the first one, and a decoded binary string for the second two.
Given our existing API, I don't think we want
string.encode('base64')
to work (taking an ascii-only unicode string and returning bytes), and
we've already agreed that adding a 'decode' method to string is not
going to happen.
We could, however, and quite possibly should, disallow
string.untransform('base64')
even though the underly module supports it. Thus we would only have
bytes-to-bytes transformations for 'base64' and its siblings, and you
would write the unicode-ascii-to-bytes transformation as:
string.encode('ascii').untransform('base64')
which has some pedagogical value :).
If you do transform('base64') on a bytestring already encoded as base64
you get a double encoding, yes. I don't see that it is our responsibility
to try to protect you from this mistake. The module functions certainly
don't.
Given that, is there anything ambiguous about the proposed API?
(Note: if you would like to argue that, eg, base64.b64encode or
binascii.b2a_base64 should return a string, it is too late for that
argument for backward compatibility reasons.)
> It is certainly true that there are many unambiguous cases. In the
> case of a true text processing facility (eg, Emacs buffers or Python 3
> str) where there is an unambiguous text type with a constant and
> opaque internal representation, it makes a lot of sense to treat the
> text type as special/central, and use the terminology "encode [from
> text]" and "decode [to text]". It's easy to remember, which one is
> special is obvious, and the difference in input and output types means
> that mistaken use of the API will be detected by duck-typing.
>
> However, in the case of bytes-bytes or text-text transformations, it's
> not the presence of unambiguous cases that should drive API design
> IMO. It's the presence of the ambiguous cases that we should cater
> to. I don't see easy solutions to this issue.
When I asked about ambiguous cases, I was asking for cases where the
meaning of "transform('somecodec')" was ambiguous. Sure, it is possible
to feed the wrong input into that transformation, but I consider that a
programming error, not an ambiguity in the API. After all, you have
exactly the same problem if you use the module functions directly,
which is currently the only option.
--David
___
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
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
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 as in-person > discussions and decisions made during the latest PyCon language > summit. We believe the proposal is now better than the original one, > providing both a wider set of features and more convenient ways to > use those features. 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.__class__ >>> isinstance(C.a, C) False >>> isinstance(C(1), C) False It would really be better if instances were actual instances of the class, IMO. Regards Antoine. ___ 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
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
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 proposal is now better than the original one,
> providing both a wider set of features and more convenient ways to
> use those features.
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:
>
> Link to the PEP: http://www.python.org/dev/peps/pep-0435/ [it's also
> pasted fully below for convenience].
>
> Reference implementation is available as the recently released
> flufl.enum version 4.0 - you can get it either from PyPi or
> https://launchpad.net/flufl.enum. flufl.enum 4.0 was developed in
> parallel with revising PEP 435.
>
> Comments welcome,
>
> Barry and Eli
>
> --
>
> PEP: 435
> Title: Adding an Enum type to the Python standard library
> Version: $Revision$
> Last-Modified: $Date$
> Author: Barry Warsaw ,
> Eli Bendersky
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 2013-02-23
> Python-Version: 3.4
> Post-History: 2013-02-23
>
>
> Abstract
>
>
> This PEP proposes adding an enumeration type to the Python standard
> library. Specifically, it proposes moving the existing ``flufl.enum``
> package by Barry
> Warsaw into the standard library. Much of this PEP is based on the
> "using" [1]_ document from the documentation of ``flufl.enum``.
>
> An enumeration is a set of symbolic names bound to unique, constant
> values. Within an enumeration, the values can be compared by
> identity, and the enumeration itself can be iterated over.
>
>
> Decision
>
>
> TODO: update decision here once pronouncement is made.
>
>
> Status of discussions
> =
>
> The idea of adding an enum type to Python is not new - PEP 354 [2]_
> is a previous attempt that was rejected in 2005. Recently a new set
> of discussions
> was initiated [3]_ on the ``python-ideas`` mailing list. Many new
> ideas were
> proposed in several threads; after a lengthy discussion Guido proposed
> adding
> ``flufl.enum`` to the standard library [4]_. During the PyCon 2013
> language summit the issue was discussed further. It became clear
> that many developers
> want to see an enum that subclasses ``int``, which can allow us to
> replace many integer constants in the standard library by enums with
> friendly string representations, without ceding backwards
> compatibility. An additional discussion among several interested
> core developers led to the proposal of having ``IntEnum`` as a
> special case of ``Enum``.
>
> The key dividing issue between ``Enum`` and ``IntEnum`` is whether
> comparing to integers is semantically meaningful. For most uses of
> enumerations, it's a **feature** to reject comparison to integers;
> enums that compare to integers
> lead, through transitivity, to comparisons between enums of unrelated
> types, which isn't desirable in most cases. For some uses, however,
> greater interoperatiliby with integers is desired. For instance, this
> is the case for
> replacing existing standard library constants (such as
> ``socket.AF_INET``) with enumerations.
>
> This PEP is an attempt to formalize this decision as well as discuss a
> number
> of variations that were discussed and can be considered for inclusion.
>
>
> Motivation
> ==
>
> *[Based partly on the Motivation stated in PEP 354]*
>
> The properties of an enumeration are useful for defining an immutable,
> related
> set of constant values that have a defined sequence but no inherent
> semantic meaning. Classic examples are days of the week (Sunday
> through Saturday) and
> school assessment grades ('A' through 'D', and 'F'). Other examples
> include error status values and states within a defined process.
>
> It is possible to simply define a sequence of values of some other
> basic type,
> such as ``int`` or ``str``, to represent discrete arbitrary values.
> However,
> an enumeration ensures that such values are distinct from any others
> including,
> importantly, values within other enumerations, and that operations
> without meaning ("Wednesday times two") are not defined for these
> values. It also provides a convenient printable representation of
> enum values without requiring
> tedious repetition while defining them (i.e. no ``GREEN = 'green'``).
>
>
> Module and type name
>
>
> We propose to add a module named ``enum`` to the standard library.
> The main type exposed by this module is ``Enum``. Hence, to import
> the ``Enum`` type user code will run::
>
> >>> from enum import Enum
>
>
> Proposed semantics for the new enumeration type
> ===
>
> Creating an Enum
> --
Re: [Python-Dev] distutils, win32, multiple C extensions
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 that needs to be referenced when building E2. If it did not, you may find this link helpful: http://www.mingw.org/wiki/CreateImportLibraries On Tue, Apr 23, 2013 at 4:18 AM, Emmanuel Bacry < emmanuel.ba...@polytechnique.fr> wrote: > 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 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. > The same kind of setup.py works fine on all platforms but Windows where it > says (during the link) that the function sof E1 that are called by E2 are > unreferenced. > I am clearly not a Windows pro ... I am using mingw32 on Windows. > Surfing the web, I understood that shared libraries work differently on > windows than on other platforms. And that I should > > 1- export the symbols (i.e., the functions) of E1 when I build E1. In the > distutils.Extension this seems to be done using > argument export_symbols=[list of symbols to export] > Now I have one problem : each time I specify in this list the name of a > function in E1 it says that it doesn't know this symbol > What am I doing wrong here, is there a special syntax ? > > 2- Now in the setup.py of E2 how do I declare that I want to use the E1 > shared lib.? Is the information on the exported symbol of E1 in the .pyd > file or in the .def file ? > I tried to specify the .pyd library in the arguments of the > distutils.Extension but I have the feeling that's not the right thing > to do (I have the feeling the .pyd is not the right file to point to) > Not mentioning the problem specifying the path of the library with > runtime_library_dirs ... which does not seem to work at all. > > Is there a simple way to do what I want to do ? > I did not find anything on the web explaining clearly what to do ... > I am really really stuck > > I would appreciate any kind of help > > > Emmanuel > > ___ > 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/curt%40hagenlocher.org > ___ 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
Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?
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?
BASE64 itself is ambiguous. 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, this has several problems. In
practice, we invariably use an ASCII octet stream to carry BASE64-
encoded data. So web developers would almost certainly expect a
bytes-to-bytes encoder. Such a bytes-to-bytes encoder can't be
duck-typed. Double-encoding bugs wouldn't be detected until the
stream arrives at the user. And the RFC-based signature of
.encode('base64') as bytes-to-text is precisely opposite to that of
.encode('utf-8') (text-to-bytes).
It is certainly true that there are many unambiguous cases. In the
case of a true text processing facility (eg, Emacs buffers or Python 3
str) where there is an unambiguous text type with a constant and
opaque internal representation, it makes a lot of sense to treat the
text type as special/central, and use the terminology "encode [from
text]" and "decode [to text]". It's easy to remember, which one is
special is obvious, and the difference in input and output types means
that mistaken use of the API will be detected by duck-typing.
However, in the case of bytes-bytes or text-text transformations, it's
not the presence of unambiguous cases that should drive API design
IMO. It's the presence of the ambiguous cases that we should cater
to. I don't see easy solutions to this issue.
Steve
___
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
[Python-Dev] distutils, win32, multiple C extensions
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 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. The same kind of setup.py works fine on all platforms but Windows where it says (during the link) that the function sof E1 that are called by E2 are unreferenced. I am clearly not a Windows pro ... I am using mingw32 on Windows. Surfing the web, I understood that shared libraries work differently on windows than on other platforms. And that I should 1- export the symbols (i.e., the functions) of E1 when I build E1. In the distutils.Extension this seems to be done using argument export_symbols=[list of symbols to export] Now I have one problem : each time I specify in this list the name of a function in E1 it says that it doesn't know this symbol What am I doing wrong here, is there a special syntax ? 2- Now in the setup.py of E2 how do I declare that I want to use the E1 shared lib.? Is the information on the exported symbol of E1 in the .pyd file or in the .def file ? I tried to specify the .pyd library in the arguments of the distutils.Extension but I have the feeling that's not the right thing to do (I have the feeling the .pyd is not the right file to point to) Not mentioning the problem specifying the path of the library with runtime_library_dirs ... which does not seem to work at all. Is there a simple way to do what I want to do ? I did not find anything on the web explaining clearly what to do ... I am really really stuck I would appreciate any kind of help Emmanuel ___ 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
