Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Python: Dev

sys.implementation

 

 

First page Previous page 1 2 3 Next page Last page  View All Python dev RSS feed   Index | Next | Previous | View Threaded


ncoghlan at gmail

May 9, 2012, 6:33 PM

Post #26 of 55 (386 views)
Permalink
Re: sys.implementation [In reply to]

On Thu, May 10, 2012 at 2:53 AM, Barry Warsaw <barry [at] python> wrote:
> On May 09, 2012, at 11:09 AM, Brett Cannon wrote:
>
>>Sure, but couldn't we define this "empty" class in C code so that you can
>>use the C API with it as well and just provide a C function to get a new
>>instance?
>
> +1
>
> ISTM to be a companion to collections.namedtuple. †IWBNI this new type was
> also exposed in the collections module.

Please, no. No new
just-like-a-namedtuple-except-you-can't-iterate-over-it type, and
definitely not one exposed in the collections module.

We've been over this before: collections.namedtuple *is* the standard
library's answer for structured records. TOOWTDI, and the way we have
already chosen includes iterability as one of its expected properties.

People shouldn't be so quick to throw away ordered iterability - it
makes a lot of things like generic display routines and serialisation
*much* easier, and without incurring the runtime cost of multiple
calls to sorted().

The original concern (that sys.implementation may differ in length
across implementations) has been eliminated by moving all
implementation specific values into sys.implementation.metadata. The
top-level record now has a consistent length for any given language
version. The fact that the length of the record may still change in
*future* versions of Python can be handled through documentation - we
can simply tell people "it's OK to iterate over the fields, and even
to use tuple unpacking, but if you want to future proof your code,
make sure to include the trailing ', *' to ignore any fields that get
added in the future".

To help focus the discussion, I am going to propose a specific (albeit
still somewhat hypothetical) use case: a cross-implementation testing
system that wants to be able to consistently capture data about the
version of Python that was tested, *without* needing implementation
specific code in the metadata capture step.

That produces the following set of requirements:

1. sys.implementation should be immutable for a given execution of Python
2. repr(sys.implementation) should display all recorded details of the
implementation
3. It should be possible to write a generic, future-proof,
serialisation of sys.implementation that captures all recorded details

collections.namedtuple meets all those requirements (_structseq
doesn't meet the last one at this point, but more on that later)

It also shows that we only need to place very minimal constraints on
sys.implementation.metadata: the type of that structure can be
entirely up to the implementation, with the only requirement being
that repr(sys.implementation.metadata) should produce a string that
accurately captures the stored information. The only
cross-implementation operation that is supported on that field would
be to take its representation.

Now, because this is going to be in the sys module, for CPython, we
would actually need to use _structseq rather than
collections.namedtuple. To do so in a useful way, _structseq should
get two new additions:
- the "_fields" attribute
- the "_asdict" method

As an added bonus, sys.float_info and sys.hash_info would also gain
the new operations.

Regards,
Nick.

--
Nick Coghlan†† |†† ncoghlan [at] gmail†† |†† Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


barry at python

May 9, 2012, 7:26 PM

Post #27 of 55 (387 views)
Permalink
Re: sys.implementation [In reply to]

On May 09, 2012, at 05:47 PM, Larry Hastings wrote:

>I like Alex Martelli's approach, which I recall was exactly this:
>
> class namespace:
> def __init__(**kwargs):
> self.__dict__ = kwargs
>
>
>That means all the initializers you pass in to the constructor get turned
>into members.

Well, "__init__(self, **kws)", but yeah. :)

-Barry
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ericsnowcurrently at gmail

May 9, 2012, 9:00 PM

Post #28 of 55 (386 views)
Permalink
Re: sys.implementation [In reply to]

On Wed, May 9, 2012 at 7:33 PM, Nick Coghlan <ncoghlan [at] gmail> wrote:
> Please, no. No new
> just-like-a-namedtuple-except-you-can't-iterate-over-it type, and
> definitely not one exposed in the collections module.
>
> We've been over this before: collections.namedtuple *is* the standard
> library's answer for structured records. TOOWTDI, and the way we have
> already chosen includes iterability as one of its expected properties.
>
> People shouldn't be so quick to throw away ordered iterability - it
> makes a lot of things like generic display routines and serialisation
> *much* easier, and without incurring the runtime cost of multiple
> calls to sorted().
>
> The original concern (that sys.implementation may differ in length
> across implementations) has been eliminated by moving all
> implementation specific values into sys.implementation.metadata. The
> top-level record now has a consistent length for any given language
> version. The fact that the length of the record may still change in
> *future* versions of Python can be handled through documentation - we
> can simply tell people "it's OK to iterate over the fields, and even
> to use tuple unpacking, but if you want to future proof your code,
> make sure to include the trailing ', *' to ignore any fields that get
> added in the future".

Good point. I'd forgotten about that new tuple unpacking syntax.
FYI, a named tuple was my original choice. I'm going to sit on this a
few days though. Who knows, we might be back to using a dict by then.
<wink>

Key points:

* has dotted access
* is immutable

Both reflect the nature of sys.implementation as currently described
(a fixed set of attributes on an dotted-access namespace).

> To help focus the discussion, I am going to propose a specific (albeit
> still somewhat hypothetical) use case: a cross-implementation testing
> system that wants to be able to consistently capture data about the
> version of Python that was tested, *without* needing implementation
> specific code in the metadata capture step.
>
> That produces the following set of requirements:
>
> 1. sys.implementation should be immutable for a given execution of Python
> 2. repr(sys.implementation) should display all recorded details of the
> implementation
> 3. It should be possible to write a generic, future-proof,
> serialisation of sys.implementation that captures all recorded details
>
> collections.namedtuple meets all those requirements (_structseq
> doesn't meet the last one at this point, but more on that later)
>
> It also shows that we only need to place very minimal constraints on
> sys.implementation.metadata: the type of that structure can be
> entirely up to the implementation, with the only requirement being
> that repr(sys.implementation.metadata) should produce a string that
> accurately captures the stored information. The only
> cross-implementation operation that is supported on that field would
> be to take its representation.

Nice.

> Now, because this is going to be in the sys module, for CPython, we
> would actually need to use _structseq rather than
> collections.namedtuple. To do so in a useful way, _structseq should
> get two new additions:
> - the "_fields" attribute
> - the "_asdict" method

Sounds good to me regardless of the PEP.

-eric
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


martin at v

May 9, 2012, 10:34 PM

Post #29 of 55 (384 views)
Permalink
Re: sys.implementation [In reply to]

> We've been over this before: collections.namedtuple *is* the standard
> library's answer for structured records.

And I think it's a really ugly answer, and one that deserves a parallel
that is not a tuple. If this is contentious, I'll write a PEP.

Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ncoghlan at gmail

May 9, 2012, 10:40 PM

Post #30 of 55 (383 views)
Permalink
Re: sys.implementation [In reply to]

On Thu, May 10, 2012 at 3:34 PM, "Martin v. LŲwis" <martin [at] v> wrote:
>> We've been over this before: collections.namedtuple *is* the standard
>> library's answer for structured records.
>
>
> And I think it's a really ugly answer, and one that deserves a parallel
> that is not a tuple. If this is contentious, I'll write a PEP.

Yes, please. One of the original arguments that delayed the
introduction of the collections module was the fear that it would lead
to the introduction of tons of subtly different data types, making it
substantially harder to choose the right data type for a given
application. I see this proposal as the realisation of that fear.

Unordered types can be a PITA for testing, for display and for generic
serialisation, so I definitely want to see a PEP before we add a new
one that basically has its sole reason for existence being "you can
iterate over and index the field values in a namedtuple".

Regards,
Nick.

--
Nick Coghlan†† |†† ncoghlan [at] gmail†† |†† Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


solipsis at pitrou

May 10, 2012, 1:57 AM

Post #31 of 55 (384 views)
Permalink
Re: sys.implementation [In reply to]

On Thu, 10 May 2012 11:33:14 +1000
Nick Coghlan <ncoghlan [at] gmail> wrote:
>
> The original concern (that sys.implementation may differ in length
> across implementations) has been eliminated by moving all
> implementation specific values into sys.implementation.metadata.

Uh. It's scary the kind of things people sometimes come up with :-)

sys.implementation.metadata looks like a completely over-engineered
concept. Please, let's just make sys.implementation a dict and stop
bothering about ordering and iterability.

Regards

Antoine.


_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ncoghlan at gmail

May 10, 2012, 3:21 AM

Post #32 of 55 (380 views)
Permalink
Re: sys.implementation [In reply to]

On Thu, May 10, 2012 at 6:57 PM, Antoine Pitrou <solipsis [at] pitrou> wrote:
> On Thu, 10 May 2012 11:33:14 +1000
> Nick Coghlan <ncoghlan [at] gmail> wrote:
>>
>> The original concern (that sys.implementation may differ in length
>> across implementations) has been eliminated by moving all
>> implementation specific values into sys.implementation.metadata.
>
> Uh. It's scary the kind of things people sometimes come up with :-)
>
> sys.implementation.metadata looks like a completely over-engineered
> concept. Please, let's just make sys.implementation a dict and stop
> bothering about ordering and iterability.

Aye. Add a rule that all implementation specific (i.e. not defined in
the PEP) keys must be prefixed with an underscore and I'm sold.

Cheers,
Nick.

--
Nick Coghlan†† |†† ncoghlan [at] gmail†† |†† Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


g.brandl at gmx

May 10, 2012, 7:42 AM

Post #33 of 55 (376 views)
Permalink
Re: sys.implementation [In reply to]

On 10.05.2012 10:57, Antoine Pitrou wrote:
> On Thu, 10 May 2012 11:33:14 +1000
> Nick Coghlan <ncoghlan [at] gmail> wrote:
>>
>> The original concern (that sys.implementation may differ in length
>> across implementations) has been eliminated by moving all
>> implementation specific values into sys.implementation.metadata.
>
> Uh. It's scary the kind of things people sometimes come up with :-)

.oO( Namespaception )

> sys.implementation.metadata looks like a completely over-engineered
> concept. Please, let's just make sys.implementation a dict and stop
> bothering about ordering and iterability.

Agreed.

Georg

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


tjreedy at udel

May 10, 2012, 8:31 AM

Post #34 of 55 (375 views)
Permalink
Re: sys.implementation [In reply to]

On 5/10/2012 10:42 AM, Georg Brandl wrote:
> On 10.05.2012 10:57, Antoine Pitrou wrote:
>> On Thu, 10 May 2012 11:33:14 +1000
>> Nick Coghlan<ncoghlan [at] gmail> wrote:
>>>
>>> The original concern (that sys.implementation may differ in length
>>> across implementations) has been eliminated by moving all
>>> implementation specific values into sys.implementation.metadata.
>>
>> Uh. It's scary the kind of things people sometimes come up with :-)
>
> .oO( Namespaception )
>
>> sys.implementation.metadata looks like a completely over-engineered
>> concept. Please, let's just make sys.implementation a dict and stop
>> bothering about ordering and iterability.

Thank you for cutting through the knot.

> Agreed.

Ditto. Iterability is good and should be part of all python collections.
People who want a sorted representation should just use sorted(d.items)
as with other sortable mappings. Nick's idea of prefixing local
implementation keys with '_' would nicely group them together on sorted
displays.

--
Terry Jan Reedy

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


scott+python-dev at scottdial

May 10, 2012, 8:34 AM

Post #35 of 55 (379 views)
Permalink
Re: sys.implementation [In reply to]

On 5/10/2012 1:40 AM, Nick Coghlan wrote:
> Unordered types can be a PITA for testing, for display and for generic
> serialisation, so I definitely want to see a PEP before we add a new
> one that basically has its sole reason for existence being "you can
> iterate over and index the field values in a namedtuple".
>

I could use those same arguments (testing, display, and generic
serialization) as reasons /against/ using an ordered type (when it's not
the intent of the author that it be ordered). That is:

- Testing: This is an attractive nuisance because adding fields later
can break the tests if the author of the type had no intent on the
ordering being guaranteed (or the number of fields).
- Display: If the author of the type didn't intend on the ordering
being guaranteed, then the display could become nonsense when changing
versions (e.g., upgrading a 3rd-party library).
- Generic Serialization: Again, if the author didn't plan for that,
then they could add additional fields or re-arrange them in a way that
makes naive serialization give incorrect instances.

The point is that the author of the type can't protect you from these
mistakes if a namedtuple is used. The only tool the author of the type
has at their disposal to warn you of your ways is documentation. If the
type doesn't support iteration or indexing, then you are forced to do it
right, because it's the only way that works.

Furthermore, what is wrong with a repr that yields a dict-like string
"record(a=1, b=2, c=3)" with regard to testing and display?

--
Scott Dial
scott [at] scottdial
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


barry at python

May 10, 2012, 11:30 AM

Post #36 of 55 (372 views)
Permalink
Re: sys.implementation [In reply to]

On May 10, 2012, at 10:57 AM, Antoine Pitrou wrote:

>sys.implementation.metadata looks like a completely over-engineered
>concept. Please, let's just make sys.implementation a dict and stop
>bothering about ordering and iterability.

I guess the question is whether immutability is useful to preserve in
sys.implementation. I'm on the fence, but maybe "we're all consenting adults"
and "simplest thing that will work" should rule the day.

Using a straight up dict and underscores for non-PEP-defined values is
certainly simple, and easy to implement and describe.

-Barry
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


steve at pearwood

May 10, 2012, 3:39 PM

Post #37 of 55 (369 views)
Permalink
Re: sys.implementation [In reply to]

Nick Coghlan wrote:
> On Thu, May 10, 2012 at 6:57 PM, Antoine Pitrou <solipsis [at] pitrou> wrote:
>> On Thu, 10 May 2012 11:33:14 +1000
>> Nick Coghlan <ncoghlan [at] gmail> wrote:
>>> The original concern (that sys.implementation may differ in length
>>> across implementations) has been eliminated by moving all
>>> implementation specific values into sys.implementation.metadata.
>> Uh. It's scary the kind of things people sometimes come up with :-)
>>
>> sys.implementation.metadata looks like a completely over-engineered
>> concept. Please, let's just make sys.implementation a dict and stop
>> bothering about ordering and iterability.
>
> Aye. Add a rule that all implementation specific (i.e. not defined in
> the PEP) keys must be prefixed with an underscore and I'm sold.

So now we're adding a new convention to single underscore names? Single
underscore names are implementation-specific details that you shouldn't use or
rely on, except in sys.implementation, where they are an optional part of the
public interface.

There are public keys which all Pythons are expected to support. There are
public keys which only some Pythons are expected to support. We may call them
"implementation-specific", but that refers to the PYTHON implementation, not
the implementation of sys.implementation. As far as sys.implementation is
concerned, these keys are public but optional, not private.

Hence labelling them with a single underscore overrides the convention that
_single underscore names are private, for one that they are public but optional.

I'm not so sure that this is a good idea.

To bike-shed a moment, if we're going to stick to a dict, and you really think
that it is important to have a naming convention to distinguish between
optional keys and those common to all Pythons, perhaps a better convention
would be to prefix the optional keys with a dot, or a dash. This introduces a
new convention without clashing with an existing one.


--
Steven

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


steve at pearwood

May 10, 2012, 3:45 PM

Post #38 of 55 (372 views)
Permalink
Re: sys.implementation [In reply to]

Scott Dial wrote:
> On 5/10/2012 1:40 AM, Nick Coghlan wrote:
>> Unordered types can be a PITA for testing, for display and for generic
>> serialisation, so I definitely want to see a PEP before we add a new
>> one that basically has its sole reason for existence being "you can
>> iterate over and index the field values in a namedtuple".
>>
>
> I could use those same arguments (testing, display, and generic
> serialization) as reasons /against/ using an ordered type (when it's not
> the intent of the author that it be ordered). That is:
>
> - Testing: This is an attractive nuisance because adding fields later
> can break the tests if the author of the type had no intent on the
> ordering being guaranteed (or the number of fields).

As opposed to unordered types when you add a new field? I don't think so.

When you add new fields, you can break tests *regardless* of whether the type
is ordered or unordered. If you change the public interface to a type, you
have to change any tests that rely on it.

But unordered types have a tendency to break tests even when you don't add new
fields (at least doctests), simply because their display can arbitrarily change.

Given the choice between having to re-write tests once in a blue moon when
there is a backwards-incompatible change to a type, and having tests randomly
break every time I run them because the display is unpredictable, I know which
one I prefer.

+1 to Nick's request for a PEP.


--
Steven
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ncoghlan at gmail

May 10, 2012, 4:14 PM

Post #39 of 55 (376 views)
Permalink
Re: sys.implementation [In reply to]

No, they're private keys for the benefit of the implementation authors.

Still, it's already the case that underscore prefixed names are sometimes
used just for namespace separation (e.g. collections.namedtuple)

--
Sent from my phone, thus the relative brevity :)


jdhardy at gmail

May 11, 2012, 10:28 AM

Post #40 of 55 (362 views)
Permalink
Re: sys.implementation [In reply to]

On Thu, May 10, 2012 at 3:39 PM, Steven D'Aprano <steve [at] pearwood> wrote:
>> Aye. Add a rule that all implementation specific (i.e. not defined in
>> the PEP) keys must be prefixed with an underscore and I'm sold.
>
>
> So now we're adding a new convention to single underscore names? Single
> underscore names are implementation-specific details that you shouldn't use
> or rely on, except in sys.implementation, where they are an optional part of
> the public interface.

I've always seen _names as less implementation details and more 'here
be dragons; tread carefully'. I don't think adding a different
convention really changes that at all.

The underscore ones would (mostly) be implementation-specific anyway.
_clr_version is something only IronPython is going to have, for
example. If more than one implementation has something it can be
promoted to a non-underscore name, but I think that will be rare. Some
of the suggested metadata (like vcs_revision and build date) could
actually be required right out of the gate, and cache_tag should be
optional.

- Jeff
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ncoghlan at gmail

May 11, 2012, 5:20 PM

Post #41 of 55 (354 views)
Permalink
Re: sys.implementation [In reply to]

The specific reason cache_tag is mandatory is so that importlib can rely on
it. Setting it to None for a given implementation will automatically
disable caching of bytecode files.

--
Sent from my phone, thus the relative brevity :)


ericsnowcurrently at gmail

May 11, 2012, 7:40 PM

Post #42 of 55 (353 views)
Permalink
Re: sys.implementation [In reply to]

On Thu, May 10, 2012 at 2:57 AM, Antoine Pitrou <solipsis [at] pitrou> wrote:
> sys.implementation.metadata looks like a completely over-engineered
> concept. Please, let's just make sys.implementation a dict and stop
> bothering about ordering and iterability.

I'm fine with ditching "metadata". The PEP will say
sys.implementation must have the required attributes and leave it at
that. However, my preference is still for dotted access rather than a
dict. The type doesn't really matter to me otherwise. Immutability
isn't a big concern nor is sequence-ness. I'll tone the type
discussion accordingly.

If anyone has strong feelings for item-access over attribute-access,
please elaborate. I'm just not seeing it as that important and would
rather finish up the PEP as simply as possible.

-eric
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ncoghlan at gmail

May 12, 2012, 5:04 AM

Post #43 of 55 (355 views)
Permalink
Re: sys.implementation [In reply to]

On Sat, May 12, 2012 at 12:40 PM, Eric Snow <ericsnowcurrently [at] gmail> wrote:
> If anyone has strong feelings for item-access over attribute-access,
> please elaborate. †I'm just not seeing it as that important and would
> rather finish up the PEP as simply as possible.

I object to adding a new type to the stdlib just for this PEP. Since
iterating over the keys is significantly more useful than iterating
over the values, that suggests a dictionary as the most appropriate
type.

If someone *really* wants a quick way to get dotted access to the
contents of dictionary:

>>> data = dict(a=1, b=2, c=3)
>>> ns = type('', (), data)
>>> ns.a
1
>>> ns.b
2
>>> ns.c
3

Cheers,
Nick.

--
Nick Coghlan†† |†† ncoghlan [at] gmail†† |†† Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


barry at python

May 12, 2012, 7:35 AM

Post #44 of 55 (355 views)
Permalink
Re: sys.implementation [In reply to]

On May 12, 2012, at 10:04 PM, Nick Coghlan wrote:

>On Sat, May 12, 2012 at 12:40 PM, Eric Snow <ericsnowcurrently [at] gmail>
>wrote: > If anyone has strong feelings for item-access over attribute-access,
>> please elaborate.  I'm just not seeing it as that important and would >
>rather finish up the PEP as simply as possible.
>
>I object to adding a new type to the stdlib just for this PEP. Since
>iterating over the keys is significantly more useful than iterating over the
>values, that suggests a dictionary as the most appropriate type.

I'm okay with dropping immutability for sys.implementation, but I still think
attribute access is a more useful model. You can easily support both getattr
and getitem with a class instance, so I think that's the way to go.

(FWIW, immutability would also be easy to support with an instance.)

-Barry
Attachments: signature.asc (0.82 KB)


tseaver at palladion

May 12, 2012, 9:51 AM

Post #45 of 55 (354 views)
Permalink
Re: sys.implementation [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/12/2012 08:04 AM, Nick Coghlan wrote:
> On Sat, May 12, 2012 at 12:40 PM, Eric Snow
> <ericsnowcurrently [at] gmail> wrote:
>> If anyone has strong feelings for item-access over
>> attribute-access, please elaborate. I'm just not seeing it as that
>> important and would rather finish up the PEP as simply as possible.
>
> I object to adding a new type to the stdlib just for this PEP. Since
> iterating over the keys is significantly more useful than iterating
> over the values, that suggests a dictionary as the most appropriate
> type.

Why would anyone want to iterate over either of them?


Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 tseaver [at] palladion
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+ulP8ACgkQ+gerLs4ltQ4OzACgwnmVgJzE+IdEdS0Ij1J357di
bnoAni5nUCIDcZt7dwEOfLLPUZoJQYF9
=t05/
-----END PGP SIGNATURE-----

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ericsnowcurrently at gmail

May 12, 2012, 10:50 AM

Post #46 of 55 (353 views)
Permalink
Re: sys.implementation [In reply to]

On Sat, May 12, 2012 at 6:04 AM, Nick Coghlan <ncoghlan [at] gmail> wrote:
> On Sat, May 12, 2012 at 12:40 PM, Eric Snow <ericsnowcurrently [at] gmail> wrote:
>> If anyone has strong feelings for item-access over attribute-access,
>> please elaborate. †I'm just not seeing it as that important and would
>> rather finish up the PEP as simply as possible.
>
> I object to adding a new type to the stdlib just for this PEP.

And I agree with you. :) The only constraint is that it be an object
with attribute access. That could be a named tuple, a module, an
uninstantiated class, or whatever. A new type is not needed. If it's
iterable or not is irrelevant with regards to the PEP. For the
implementation I'd like it to have a good repr too, but even that's
not part of the proposal.

I've got the latest version of the PEP up now. It pares down the type
discussion and eliminates "metadata". I figure it's good enough for
what we need, and I've put adequate(?) warning that people shouldn't
mess with it (consenting adults, etc.). Let me know what you think.

> Since
> iterating over the keys is significantly more useful than iterating
> over the values, that suggests a dictionary as the most appropriate
> type.
>
> If someone *really* wants a quick way to get dotted access to the
> contents of dictionary:
>
>>>> data = dict(a=1, b=2, c=3)
>>>> ns = type('', (), data)
>>>> ns.a
> 1
>>>> ns.b
> 2
>>>> ns.c
> 3

That's pretty cool. As a counter example, given a normal (dict-based)
object you can use vars() to turn it into a dict:

>>> data = SomeClass(a=1, b=2, c=3)
>>> ns = vars(data)
>>> ns['a']
1
>>> ns['b']
2
>>> ns['c']
3

I'll grant that it doesn't work for some objects (like named tuples),
but for sys.implementation I don't think it matters either way.

-eric
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ericsnowcurrently at gmail

May 12, 2012, 10:57 AM

Post #47 of 55 (352 views)
Permalink
Re: sys.implementation [In reply to]

On Sat, May 12, 2012 at 8:35 AM, Barry Warsaw <barry [at] python> wrote:
> I'm okay with dropping immutability for sys.implementation, but I still think
> attribute access is a more useful model. †You can easily support both getattr
> and getitem with a class instance, so I think that's the way to go.
>
> (FWIW, immutability would also be easy to support with an instance.)

Agreed on both counts. The precedent in sys and elsewhere favors
attribute access for a fixed namespace like sys.implementation. Also,
item access (a la mappings) implies a more volatile namespace.

-eric
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ericsnowcurrently at gmail

May 12, 2012, 11:02 AM

Post #48 of 55 (353 views)
Permalink
Re: sys.implementation [In reply to]

On Sat, May 12, 2012 at 10:51 AM, Tres Seaver <tseaver [at] palladion> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 05/12/2012 08:04 AM, Nick Coghlan wrote:
>> On Sat, May 12, 2012 at 12:40 PM, Eric Snow
>> <ericsnowcurrently [at] gmail> wrote:
>>> If anyone has strong feelings for item-access over
>>> attribute-access, please elaborate. †I'm just not seeing it as that
>>> important and would rather finish up the PEP as simply as possible.
>>
>> I object to adding a new type to the stdlib just for this PEP. Since
>> iterating over the keys is significantly more useful than iterating
>> over the values, that suggests a dictionary as the most appropriate
>> type.
>
> Why would anyone want to iterate over either of them?

Nick gave a pretty good example [1]. I just don't think it's
necessary for the PEP.

-eric


[1] http://mail.python.org/pipermail/python-dev/2012-May/119412.html
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


steve at pearwood

May 12, 2012, 11:07 AM

Post #49 of 55 (354 views)
Permalink
Re: sys.implementation [In reply to]

Tres Seaver wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 05/12/2012 08:04 AM, Nick Coghlan wrote:
>> On Sat, May 12, 2012 at 12:40 PM, Eric Snow
>> <ericsnowcurrently [at] gmail> wrote:
>>> If anyone has strong feelings for item-access over
>>> attribute-access, please elaborate. I'm just not seeing it as that
>>> important and would rather finish up the PEP as simply as possible.
>> I object to adding a new type to the stdlib just for this PEP. Since
>> iterating over the keys is significantly more useful than iterating
>> over the values, that suggests a dictionary as the most appropriate
>> type.
>
> Why would anyone want to iterate over either of them?

1) I don't know what keys exist, so I use introspection on sys.implementation
by iterating over the keys and/or values. E.g. dir(sys.implementation), or
list(sys.implementation.keys()).

2) I know what keys exist, but I want to pretty-print the list of key/value
pairs without having to explicitly write them out by hand:

print("spam", sys.implementation.spam)
print("ham", sys.implementation.ham)
print("cheese", sys.implementation.cheese)
# and so on...




--
Steven
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


v+python at g

May 12, 2012, 2:25 PM

Post #50 of 55 (354 views)
Permalink
Re: sys.implementation [In reply to]

On 5/12/2012 10:50 AM, Eric Snow wrote:
> given a normal (dict-based)
> object you can use vars() to turn it into a dict:
>
>>>> >>> data = SomeClass(a=1, b=2, c=3)
>>>> >>> ns = vars(data)
>>>> >>> ns['a']
> 1
>>>> >>> ns['b']
> 2
>>>> >>> ns['c']
> 3
>
> I'll grant that it doesn't work for some objects (like named tuples),

Why not? Seems like it could, with a tweak to vars ...

named tuples already have a method to return a dict.
vars already has a special case to act like locals.

So why not add a special case to allow vars to work on named tuples?

First page Previous page 1 2 3 Next page Last page  View All Python dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.