Re: [Python-Dev] Compact ordered dict is not ordered for split table. (was: PEP XXX: Compact ordered dict

[INADA Naoki]

>> Another idea (though it has several issues and seems like a step backward):
>> a split-table dict can have a separate iteration list, indexing into the
>> entry table. There are ways to share iteration lists, and make it so that
>> adding the same keys in the same order each time results in the same
>> iteration list each time, but this costs overhead. There might be ways of
>> reducing the overhead, or the overhead might be replacing bigger overhead,
>> but we should decide if the behavior is what we want in the first place.
>>
>
> I'll test some ideas.
>
> But for now, I'll update http://bugs.python.org/issue27350 to stop key
> sharing when
> order is different.  (a. deletion is not allowed, and insertion order
> must be same).
>
> It may reduce key sharing rate, but total memory usage must not increase so
> much thanks to compact dict.


I did it.  issue27350 is now ordered for key sharing dict, too.

-- 
INADA Naoki  
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] When to use EOFError?

[André Malo]

* Serhiy Storchaka wrote:

> On 22.06.16 19:22, André Malo wrote:
> > I often concatenate multiple pickles into one file. When reading them,
> > it works like this:
> >
> > try:
> >  while True:
> >  yield pickle.load(fp)
> > except EOFError:
> >  pass
> >
> > In this case the truncation is not really unexpected. Maybe it should
> > distinguish between truncated-in-the-middle and
> > truncated-because-empty.
> >
> > (Same goes for marshal)
>
> This is interesting application, but works only for non-truncated data.
> If the data is truncated, you just lose the last item without a notice.

Yes (as said). In my case it's typically not a problem, because I write them 
myself right before reading them. It's a basically about spooling data to 
disk in order to keep them out of the RAM.
However, because of the truncation issue it would be nice, to have a 
distinction between no-data and truncated-data.

Cheers,
-- 
Winnetous Erbe: 
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] When to use EOFError?

[Guido van Rossum]

I think this is an interesting idea and quite in line with the meaning of
EOFError.

--Guido (mobile)
On Jun 26, 2016 5:02 AM, "André Malo"  wrote:

> * Serhiy Storchaka wrote:
>
> > On 22.06.16 19:22, André Malo wrote:
> > > I often concatenate multiple pickles into one file. When reading them,
> > > it works like this:
> > >
> > > try:
> > >  while True:
> > >  yield pickle.load(fp)
> > > except EOFError:
> > >  pass
> > >
> > > In this case the truncation is not really unexpected. Maybe it should
> > > distinguish between truncated-in-the-middle and
> > > truncated-because-empty.
> > >
> > > (Same goes for marshal)
> >
> > This is interesting application, but works only for non-truncated data.
> > If the data is truncated, you just lose the last item without a notice.
>
> Yes (as said). In my case it's typically not a problem, because I write
> them
> myself right before reading them. It's a basically about spooling data to
> disk in order to keep them out of the RAM.
> However, because of the truncation issue it would be nice, to have a
> distinction between no-data and truncated-data.
>
> Cheers,
> --
> Winnetous Erbe: 
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 487: Simpler customization of class creation

[Guido van Rossum]

 > One of the big issues that makes library authors reluctant to use
metaclasses
> (even when they would be appropriate) is the risk of metaclass conflicts.

Really? I've written and reviewed a lot of metaclasses and this has never
worried me. The problem is limited to multiple inheritance, right? I worry
a lot about MI being imposed on classes that weren't written with MI in
mind, but I've never particularly worried about the special case of
metaclasses.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 520: Preserving Class Attribute Definition Order (round 5)

[Guido van Rossum]

On Fri, Jun 24, 2016 at 3:46 PM, Eric Snow 
wrote:

> On Fri, Jun 24, 2016 at 4:37 PM, Nick Coghlan  wrote:
> > This version looks fine to me.
>
> \o/
>

Same to me, mostly.


> > The definition order question has been dropped from PEP 487, so this
> > cross-reference doesn't really make sense any more :)
>
> Ah, so much for my appeal to authority. 
>
> > I'd characterise this section at the language definition level as the
> > default class definition namespace now being *permitted* to be an
> > OrderedDict. For implementations where dict is ordered by default,
> > there's no requirement to switch specifically to
> > collections.OrderedDict.
>
> Yeah, I'd meant to fix that.
>

Please do.


> > This paragraph is a little confusing, since "set
> > ``__definition_order__`` manually" is ambiguous.
> >
> > "supply an explicit ``__definition_order__`` via the class namespace"
> > might be clearer.
>
> ack
>
> > I realised there's another important reason for doing it this way by
> > default: it's *really easy* to write a "skip_dunder_names" filter that
> > leaves out dunder names from an arbitrary interable of strings. It's
> > flatout *impossible* to restore the dunder attribute order if the
> > class definition process throws it away.
>
> Yep.  That's why I felt fine with relaxing that.  I guess I didn't
> actually put that in the PEP though. :)
>

Please add it. I'd also like the PEP point out that there might be other
things that an app wouldn't want in the definition order, e.g. anything
that's a method, or anything that starts with '_', etc.

I still think that it should not be read-only. If __slots__ and __name__
can be writable I think __definition_order__ can be too. (I believe an easy
way to make it so should be to add it to the dict that's passed to
type.__new__().)

Other nits:

- I don't think it's great to let other implementations leave
__definition_order__ set to None when they don't care to support it; this
would break apps/libraries that want to use it and the implementation could
refuse to fix it, claiming PEP 520 doesn't mandate it. I think it's better
to mandate this from a confirming implementation.

- I don't think there's much of a use case for setting __definition_order__
(to a tuple) for builtin classes. However I do think extension modules
should be allowed to set it, in case they are substituting for a previous
Python-level class whose users expect this to work.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] When to use EOFError?

[Rob Cliffe]

So how about an EmptyFileError (or similar name) as a subclass of EOFError?


On 26/06/2016 21:42, Guido van Rossum wrote:


I think this is an interesting idea and quite in line with the meaning 
of EOFError.


--Guido (mobile)

On Jun 26, 2016 5:02 AM, "André Malo" > wrote:


* Serhiy Storchaka wrote:

> On 22.06.16 19:22, André Malo wrote:
> > I often concatenate multiple pickles into one file. When
reading them,
> > it works like this:
> >
> > try:
> >  while True:
> >  yield pickle.load(fp)
> > except EOFError:
> >  pass
> >
> > In this case the truncation is not really unexpected. Maybe it
should
> > distinguish between truncated-in-the-middle and
> > truncated-because-empty.
> >
> > (Same goes for marshal)
>
> This is interesting application, but works only for
non-truncated data.
> If the data is truncated, you just lose the last item without a
notice.

Yes (as said). In my case it's typically not a problem, because I
write them
myself right before reading them. It's a basically about spooling
data to
disk in order to keep them out of the RAM.
However, because of the truncation issue it would be nice, to have a
distinction between no-data and truncated-data.

Cheers,
--
Winnetous Erbe: 
___
Python-Dev mailing list
Python-Dev@python.org 
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/guido%40python.org



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/rob.cliffe%40btinternet.com


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] When to use EOFError?

[Guido van Rossum]

But that use case is not about an empty file. It's about finding nothing at
the current position where something was expected. This is similar to the
original use case for EOFError, which was raised by input() (or rather,
raw_input()) when there was no more data on sys.stdin.

On Sun, Jun 26, 2016 at 5:22 PM, Rob Cliffe 
wrote:

> So how about an EmptyFileError (or similar name) as a subclass of EOFError?
>
> On 26/06/2016 21:42, Guido van Rossum wrote:
>
> I think this is an interesting idea and quite in line with the meaning of
> EOFError.
>
> --Guido (mobile)
> On Jun 26, 2016 5:02 AM, "André Malo"  wrote:
>
>> * Serhiy Storchaka wrote:
>>
>> > On 22.06.16 19:22, André Malo wrote:
>> > > I often concatenate multiple pickles into one file. When reading them,
>> > > it works like this:
>> > >
>> > > try:
>> > >  while True:
>> > >  yield pickle.load(fp)
>> > > except EOFError:
>> > >  pass
>> > >
>> > > In this case the truncation is not really unexpected. Maybe it should
>> > > distinguish between truncated-in-the-middle and
>> > > truncated-because-empty.
>> > >
>> > > (Same goes for marshal)
>> >
>> > This is interesting application, but works only for non-truncated data.
>> > If the data is truncated, you just lose the last item without a notice.
>>
>> Yes (as said). In my case it's typically not a problem, because I write
>> them
>> myself right before reading them. It's a basically about spooling data to
>> disk in order to keep them out of the RAM.
>> However, because of the truncation issue it would be nice, to have a
>> distinction between no-data and truncated-data.
>>
>> Cheers,
>> --
>> Winnetous Erbe: 
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>>
>
>
> ___
> Python-Dev mailing 
> listPython-Dev@python.orghttps://mail.python.org/mailman/listinfo/python-dev
>
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/rob.cliffe%40btinternet.com
>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] [RELEASED] Python 3.4.5 and Python 3.5.2 are now available

[Larry Hastings]

On behalf of the Python development community and the Python 3.4 and 
Python 3.5 release teams, I'm thrilled to announce the availability of 
Python 3.4.5 and Python 3.5.2.


Python 3.4 is now in "security fixes only" mode.  This is the final 
stage of support for Python 3.4.  All changes made to Python 3.4 since 
Python 3.4.4 should be security fixes only; conventional bug fixes are 
not accepted.  Also, Python 3.4.5 and all future releases of Python 3.4 
will only be released as source code--no official binary installers will 
be produced.


Python 3.5 is still in active "bug fix" mode.  Python 3.5.2 contains 
many incremental improvements and bug fixes over Python 3.5.1.



You can find Python 3.4.5 here:

https://www.python.org/downloads/release/python-345/

And you can find Python 3.5.2 here:

https://www.python.org/downloads/release/python-352/


Releasing software from 30,000 feet,


//arry

/p.s. There appears to be a small oops with the Windows installers for 
3.5.2--uploaded to the wrong directory or something. They'll be 
available soon, honest!
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 520: Preserving Class Attribute Definition Order (round 5)

[Armin Rigo]

Hi,

On 24 June 2016 at 23:52, Eric Snow  wrote:
> Pending feedback, the impact on Python implementations is expected to
> be minimal.  If a Python implementation cannot support switching to
> `OrderedDict``-by-default then it can always set ``__definition_order__``
> to ``None``.

That's wishful thinking.  Any Python implementation that sets
``__definition_order__`` to None where CPython sets it to something
useful is likely going to break programs and be deemed not fully
compatible.  (Note: this PEP is not a problem for PyPy.)


A bientôt,

Armin.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com