Re: [Python-Dev] Yearly PyPI breakage

2016-05-04 Thread Stefan Krah 
  sdamon.com> writes:
> You posted a mean-spirited complaint about a policy that is nearly exactly
> two years old, to the wrong list, and call out the people calmly trying to
> explain what happened and why, and how you can mitigate it for your own work

Yeah, right.  This is distutils-sig level.  Read Glyph's "calm" and "nice"
post again.  Also note that *I* had already bowed out of the thread when
Glyph unnecessarily decided to spread complete misinformation.


Stefan Krah





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

Re: [Python-Dev] Yearly PyPI breakage

2016-05-04 Thread Glyph 
On May 3, 2016, at 9:15 PM, Stefan Krah  wrote:
> 
>> [cut overlong post]
> 
> Glyph,
> 
> nice sneaky way to try to divert from the original issue.

The original issue, as I understood it, at the start of the thread was "which 
hoops I have to jump through this year in order to keep pip downloads working". 
 So I showed you the hoops.

Your question implied, to me, that you were not presently aware of how easy it 
is to simply build and upload your packages with sdist and twine.  After years 
and years of horrible setuptools bugs, it certainly seemed plausible to me that 
if you had long-standing experience with python packaging, you might have 
perhaps developed a well-deserved low opinion of them in the past.  Therefore, 
you might not be aware of relatively recent improvements to the packaging 
ecosystem which made this problem trivial to solve.

My intent was, therefore, simply to demonstrate that things have improved, and 
that this was not a hard thing for you to do and could be resolved with a 
minimum of fuss.

I confess that before posting I was made aware that you'd had some personality 
conflicts with some PyPI maintainers in the past.  But that sentence was about 
the extent and detail level of my understanding.  I was not aware to what 
extent, and the reason I jumped into this particular thread, when I rarely 
participate in python-dev, was that I hoped a simple explanation of the facts 
of the matter from someone you hadn't previously interacted with could address 
your concerns.

> Your whole post is invalidated by the simple fact that the URL was protected 
> by a hash (which I repeatedly asked to be upgraded to sha256).

Based only on previous discussion here, I had no way to know either of those 
things.  You didn't reference it in the post I was replying to, or in your 
original post.  And, as you say later, PyPI's download URL doesn't include the 
hash any more, so it wasn't there for me to observe.  (There were some manual 
instructions in your package description but no automated tooling will honor 
that.)  In any case, fragment hashes are not really a suitable general-purpose 
mechanism as they are only honored by specific tools (like pip) whereas HTTPS 
verification ought to be universally supported, so IMHO it is a good thing that 
PyPI is discouraging their use for this purpose.

> This was the official scheme promoted by PEP-438, which you should know.  But 
> of course your actual intention here is character assassination, pretending 
> to "rescue" cdecimal

In the "overlong" post that you elided, I specifically said I didn't intend to 
maintain it for long. If this wasn't clear, what I meant to say by that comment 
was that I would keep the index entry available until you had the opportunity 
to upload some sdists and wheels yourself to PyPI.  If you don't intend to, I 
am not the right person to "rescue" the package; someone else who is more 
invested in cdecimal should provide an alternate PyPI entry, or take over this 
one.

> and trying to divert from the fact that
> the transition to PEP 470 was handled suboptimally.

I don't see any need to divert attention from this fact, because you appear to 
be in a minority of one in considering it so.

> The very reason for this thread is that the security was silently disabled 
> WITHOUT me getting a notification.  What is on PyPI *now* is not what I 
> configured!

If that was the reason for the thread, you would have been better served by 
making that specific complaint rather than asking for information, and then 
yelling at the people who provided it to you.  You might also consider 
reporting these issues to an appropriate forum, since python-dev is not the 
bugtracker for PyPI.  You can find that here: 
>.  You might also want to continue 
this thread on distutils-sig; I'm sorry for contributing to the noise on 
python-dev, but I thought getting a high-profile package such as cdecimal 
integrated into the modern packaging ecosystem would be worth the off-topic 
digression.

> [various spurious and irrelevant ad-hominem attacks redacted]


Perhaps naively, given the level of hostility on display here, I still hope 
that you might see the wisdom in simply uploading build artifacts to PyPI.  But 
I won't try to convince you further.

-glyph

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

[Python-Dev] Restore functions pickling

2016-05-04 Thread Всеволод Величко 
Hello,

I was recently porting my application from Py2 to Py3 and encountered
error, when I accidentally became unable to define my own pickling
mechanism for functions.
Before that I was using it to pickle pure lambdas, registering my own
handler for cPickle with copy_reg, but after [1] (and release 3.4) it seems
that feature has been removed.

As it mentioned in commit message, this was done for compatibility with
pure-python pickle. So I have to ask, may be it would be better to revert
the commit and add the corresponding feature to pure-python pickle
implementation?


[1] https://hg.python.org/cpython/rev/6bd1f0a27e8e

-- 
Best wishes,
Vsevolod Velichko
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Restore functions pickling

2016-05-04 Thread Brett Cannon 
On Wed, 4 May 2016 at 11:39 Всеволод Величко 
wrote:

> Hello,
>
> I was recently porting my application from Py2 to Py3 and encountered
> error, when I accidentally became unable to define my own pickling
> mechanism for functions.
> Before that I was using it to pickle pure lambdas, registering my own
> handler for cPickle with copy_reg, but after [1] (and release 3.4) it seems
> that feature has been removed.
>
> As it mentioned in commit message, this was done for compatibility with
> pure-python pickle. So I have to ask, may be it would be better to revert
> the commit and add the corresponding feature to pure-python pickle
> implementation?
>
>
> [1] https://hg.python.org/cpython/rev/6bd1f0a27e8e
>

If you want to provide a patch to implement function pickling in pure
Python code and make this work with both pickle.py and _pickle.c we might
be up for accepting the patch. You can also open an issue requesting
pickling support for functions at bugs.python.org to keep track of the
request and see if anyone else is interested in the feature.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Restore functions pickling

2016-05-04 Thread Всеволод Величко 
Super, since you are not against this feature, I created the issue with the
pach[1].
Hopefully you or one of your colleagues will have some time to review it.

(I signed the contributor form, changes just not reached the bugtracker yet)

[1] http://bugs.python.org/issue26959

2016-05-04 21:55 GMT+03:00 Brett Cannon :

>
>
> On Wed, 4 May 2016 at 11:39 Всеволод Величко 
> wrote:
>
>> Hello,
>>
>> I was recently porting my application from Py2 to Py3 and encountered
>> error, when I accidentally became unable to define my own pickling
>> mechanism for functions.
>> Before that I was using it to pickle pure lambdas, registering my own
>> handler for cPickle with copy_reg, but after [1] (and release 3.4) it seems
>> that feature has been removed.
>>
>> As it mentioned in commit message, this was done for compatibility with
>> pure-python pickle. So I have to ask, may be it would be better to revert
>> the commit and add the corresponding feature to pure-python pickle
>> implementation?
>>
>>
>> [1] https://hg.python.org/cpython/rev/6bd1f0a27e8e
>>
>
> If you want to provide a patch to implement function pickling in pure
> Python code and make this work with both pickle.py and _pickle.c we might
> be up for accepting the patch. You can also open an issue requesting
> pickling support for functions at bugs.python.org to keep track of the
> request and see if anyone else is interested in the feature.
>



-- 
Best wishes,
Vsevolod Velichko
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Yearly PyPI breakage

2016-05-04 Thread Nick Coghlan 
On 4 May 2016 at 05:06, Stefan Krah  wrote:
>
> Hello,
>
> Could someone enlighten me which hoops I have to jump through
> this year in order to keep pip downloads working?

Stefan,

I know you're not happy with myself and the other distutils-sig folks
regarding the decision to deprecate and remove automatic link
spidering, nor with the PSF regarding the current Terms of Service
around uploads to PyPI, but that doesn't make it OK to start off-topic
threads on python-dev just because you're a CPython core developer in
addition to being a PyPI user.

It *definitely* doesn't make it OK to accuse people of conspiring
against you when they answer your question in good faith, just because
their answer is the official distutils-sig/PyPA one (which was
approved through the PEP process in PEP 470).

Depending on which aspect is most bothering you right now, potential
courses of action worth pursuing include:

- writing to psf-legal to let them know whether or not Van Lindberg's
draft updates to the Terms of Service would be sufficient to make you
comfortable with uploading cdecimal to PyPI in addition to bundling it
with the standard library under your existing Contributor Licensing
Agreement: https://bitbucket.org/vanl/pypi/src/default/templates/confirm.pt

- writing to distutils-sig to see what opportunities exist to assist
with the migration from the fragile legacy PyPI codebase to the new
Warehouse implementation (which is a technical debt reduction activity
currently blocking a lot of other enhancements to the PyPI ecosystem)

- writing to the PSF Board asking us to increase the PSF's level of
investment in PyPI infrastructure support (while we're already aware
of that need, we're also the right venue to escalate these kinds of
concerns for folks that don't have the time or inclination to get
directly involved in improving the situation themselves)

Regards,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Yearly PyPI breakage

2016-05-04 Thread Nick Coghlan 
On 4 May 2016 at 13:44,   wrote:
>>
>> (Is cdecimal substantially different from the _decimal added in 3.5?)
>>
> AFAICT, they are unrelated codebases that do about the same thing with the 
> same amount of performance, with the main exception that _decimal in 3.5 does 
> not require one to change their import (or to compile the package themselves.)

cdecimal and the standard library's _decimal module are built around
the same decimal arithmetic library (libmpdec), and Stefan is the
maintainer for all of them. Similar to other standard library modules
with a PyPI counterpart, end users can choose between using the
standard library version (and avoiding the external dependency) and
using the independently updated version (and gaining increased
consistency across Python versions, including availability on 2.7).

More info on that can be found in the Python 3.3 What's New doc:
https://docs.python.org/3/whatsnew/3.3.html#new-decimal

Regards,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com