[Python-Dev] we would like to share python articles with you

[Yaroslav Lehenchuk]

Hi!

I like your resource. We in Django Stars writing a lot about Python/Django
and we would like to share our articles with other professionals and geeks.
Here are two examples of our blog content:
http://djangostars.com/blog/continuous-integration-circleci-
vs-travisci-vs-jenkins/
http://djangostars.com/blog/how-to-create-and-deploy-a-telegram-bot/

And we also have an account on git hub where we sharing our libraries and
open source projects.

Tell me please, are you interested in such cooperation? I am talking about
submitting our post to your tips-digest.

Waiting for your response. Thank you in advance.
-- 
Best Regards,
Yaroslav Lehenchuk
Marketer at Django Stars

Cell: +380730903748
Skype: yaroslav_le
Email: yaroslav.lehenc...@djangostars.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] PEP 538: Coercing the legacy C locale to a UTF-8 based locale

[Nick Coghlan]

On 6 March 2017 at 00:39, INADA Naoki  wrote:
> I prefer just "locale-aware" / "locale-independent" (application |
> library | function)
> to "locale-aware C/C++ application" / "C/C++ independent" here.

Good point, I'll fix that in the next update.

> Backporting to Python 3.6.0
> > ---
> >
> > If this PEP is accepted for Python 3.7, redistributors backporting the
> > change
> > specifically to their initial Python 3.6.0 release will be both allowed
> and
> > encouraged. However, such backports should only be undertaken either in
> > conjunction with the changes needed to also provide a suitable locale by
> > default, or else specifically for platforms where such a locale is
> already
> > consistently available.
> >
>
> If it's really encouraged, how about providing patch officially, or
> backport it in 3.6.2
> but disabled by default?
> Some Python users (including my company) uses pyenv or pythonz to
> build Python from source. This PEP and PEP 540 are important for them too.
>

For PEP 540, the changes are too intrusive to consider it a reasonable
candidate for backporting to an earlier feature release, so for that
aspect, we'll *all* be waiting for 3.7.

For this PEP, while it's deliberately unobtrusive to make it more
backporting friendly, 3.7 isn't *that* far away, and I didn't think to
seriously pursue this approach until well after the 3.6 beta deadline for
new features had passed. With it being clearly outside the normal bounds of
what's appropriate for a cross-platform maintenance release, that means the
only folks that can consider it for earlier releases are those building
their own binaries for more constrained target environments.

I can definitely make sure the patch is readily available for anyone that
wants to apply it to their own builds, though (I'll upload it to both the
Python tracker issue and the downstream Fedora Bugzilla entry).

I also wouldn't completely close the door on the idea of classifying the
change as a bug fix in CPython's handling of the C locale (and hence adding
to a latter 3.6.x feature release), but I think the time to pursue that
would be *after* we've had a chance to see how folks react to the
redistributor customizations. I *think* it will be universally positive
(because the status quo really is broken), but it also wouldn't be the
first time I've learned something new and confusing about the locale
subsystem only after releasing software that relied on an incorrect
assumption about it :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] we would like to share python articles with you

[Michel Desmoulin]

This mailling list is for coordinating the development of the Python
programming language, not to be used for marketing.

Share your articles on a social network or a forum such as
reddit.com/r/python.

Le 06/03/2017 à 16:53, Yaroslav Lehenchuk a écrit :
> Hi! 
> 
> I like your resource. We in Django Stars writing a lot about
> Python/Django and we would like to share our articles with other
> professionals and geeks.
> Here are two examples of our blog content: 
> http://djangostars.com/blog/continuous-integration-circleci-vs-travisci-vs-jenkins/
> 
>  
> http://djangostars.com/blog/how-to-create-and-deploy-a-telegram-bot/
> 
> 
> And we also have an account on git hub where we sharing our libraries
> and open source projects.
> 
> Tell me please, are you interested in such cooperation? I am talking
> about submitting our post to your tips-digest.
> 
> Waiting for your response. Thank you in advance.
> 
> -- 
> Best Regards,
> Yaroslav Lehenchuk
> Marketer at Django Stars
> 
> Cell: +380730903748
> Skype: yaroslav_le
> Email: yaroslav.lehenc...@djangostars.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/desmoulinmichel%40gmail.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] API design: where to add async variants of existing stdlib APIs?

[Raymond Hettinger]

> On Mar 1, 2017, at 8:47 AM, Yury Selivanov  wrote:
> 
>> IMHO this is a good idea*iff*  the new APIs really are bound to
>> asyncio, rather than being generic across all uses of async/await.
> 
> I agree.  There is no need to make asynccontextmanager and
> AsyncExitStack dependent on asyncio or specific to asyncio.
> 
> They should both stay framework agnostic (use only protocols
> defined by PEP 492 and PEP 525) and both shouldn't be put
> into asyncio package.

Of course, it makes sense that anything not specific to asyncio should go 
outside of asyncio.

What I'm more concerned about is what the other places actually are.   Rather 
than putting async variants of everything sprinkled all over the standard 
library, I suggest collecting them all together, perhaps in a new asynctools 
module.


Raymond
___
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] API design: where to add async variants of existing stdlib APIs?

[Guido van Rossum]

On Mon, Mar 6, 2017 at 5:57 PM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:

> Of course, it makes sense that anything not specific to asyncio should go
> outside of asyncio.
>
> What I'm more concerned about is what the other places actually are.
>  Rather than putting async variants of everything sprinkled all over the
> standard library, I suggest collecting them all together, perhaps in a new
> asynctools module.
>

That's a tough design choice. I think neither extreme is particularly
attractive -- having everything in an asynctools package might also bundle
together thing that are entirely unrelated. In the extreme it would be like
proposing that all metaclasses should go in a new "metaclasstools" package.
I think we did a reasonable job with ABCs: core support goes in abc.py,
support for collections ABCs goes into the collections package (in a
submodule), and other packages and modules sometimes define ABCs for their
own users.

Also, in some cases I expect we'll have to create a whole new module
instead of updating some ancient piece of code with newfangled async
variants to its outdated APIs.

-- 
--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