On Dec 10, 2017, at 19:36, Ryan Gonzalez wrote:
>
> Question: why is this using GitLab while CPython itself is using GitHub +
> Travis?
Mostly because Brett gave me the option to use GitLab for importlib_resources,
and this grew out of that. Enjoy!
overturn-pep-507-ly y’rs,
-Barry
signatu
Question: why is this using GitLab while CPython itself is using GitHub +
Travis?
On December 10, 2017 6:13:53 PM CST, Barry Warsaw wrote:
>As part of our work on importlib_resources, and with some fantastic
>help from Abhilash Raj, we now have a mostly official Python
>development container ima
As part of our work on importlib_resources, and with some fantastic help from
Abhilash Raj, we now have a mostly official Python development container image
that you can use for CI testing and other development purposes.
This image is based on Ubuntu 16.04 LTS and provides the latest stable rele
>
> Could you explain why not? utf-8 seems like the common thread for using
> surrogateescape so I'm not sure what would make en_US.UTF-8 different than
> C.UTF-8.
>
Because there are many lang_COUNTRY.UTF-8 locales:
ja_JP.UTF-8, zh_TW.UTF-8, fr_FR.UTF-8, etc...
If only en_US.UTF-8 should use sur
Le 10 déc. 2017 23:10, "Ned Deily" a écrit :
> But on the other, it does add a large non-zero burden to all core
developers (...)
I reviewed some of the Android' pull requests. Most changes are small and
self contained.
> As long as Xavier is willing to keep supporting the platform, the first
re
Xavier is working on fixing random issues specific to Android since 2
years. He is almost done, the last step is just to add a build infra to get
a buildbot.
https://github.com/python/cpython/pull/1629
https://bugs.python.org/issue30386
It's a set of scripts to cross compile Python from Linux to
On 12/10/2017 5:00 PM, Raymond Hettinger wrote:
On Dec 10, 2017, at 1:37 PM, Eric V. Smith wrote:
On 12/10/2017 4:29 PM, Ivan Levkivskyi wrote:
On 10 December 2017 at 22:24, Raymond Hettinger
mailto:raymond.hettin...@gmail.com>> wrote:
Without typing (only the first currently works):
I think someone may have to mentor Xavier on how to get this accepted. The
note already looks a bit like a PEP, but I suspect that Xavier is not
sufficiently familiar with our process to realize the difference.
On Sun, Dec 10, 2017 at 2:07 PM, Ned Deily wrote:
> On Dec 10, 2017, at 16:26, Guido
Sure. I think it's a good idea to make this a guaranteed language behavior,
and it doesn't need a PEP.
On Sun, Dec 10, 2017 at 1:52 PM, Larry Hastings wrote:
>
> Can I get a ruling on this? I got +1s from the community, but as it's a
> (minor) language thing I feel like you're the only one who
On Dec 10, 2017, at 16:26, Guido van Rossum wrote:
> On Dec 10, 2017 12:29, "Brett Cannon" wrote:
>> On Sun, 10 Dec 2017 at 06:19 Xavier de Gaye wrote:
>>> The following note is a proposal to add the support of the Android platform.
>>> [...]
>> While the note from a technical standpoint is inte
> On Dec 10, 2017, at 1:37 PM, Eric V. Smith wrote:
>
> On 12/10/2017 4:29 PM, Ivan Levkivskyi wrote:
>> On 10 December 2017 at 22:24, Raymond Hettinger
>> mailto:raymond.hettin...@gmail.com>> wrote:
>>Without typing (only the first currently works):
>> Point = namedtuple('Point',
On 12/10/2017 4:29 PM, Ivan Levkivskyi wrote:
On 10 December 2017 at 22:24, Raymond Hettinger
mailto:raymond.hettin...@gmail.com>> wrote:
Without typing (only the first currently works):
Point = namedtuple('Point', ['x', 'y', 'z']) #
underlying store is a tuple
I'm not familiar with software development on/for Android, but
wouldn't official support also involve suitable package creation or
does that just fall out for free from the build-for-emulator PR?
Skip
___
Python-Dev mailing list
Python-Dev@python.org
htt
On 10 December 2017 at 22:24, Raymond Hettinger wrote:
> Without typing (only the first currently works):
>
> Point = namedtuple('Point', ['x', 'y', 'z']) # underlying
> store is a tuple
> Point = make_dataclass('Point', ['x', 'y', 'z']) # underlying
> store is an instance d
Maybe it should be a PEP?
On Dec 10, 2017 12:29, "Brett Cannon" wrote:
> While the note from a technical standpoint is interest, Xavier, I don't
> quite see what needs to be done to support Android at this point. Are you
> simply asking we add Android API 24 as an official platform? Or permissio
The make_dataclass() factory function in the dataclasses module currently
requires type declarations. It would be nice if the type declarations were
optional.
With typing (currently works):
Point = NamedTuple('Point', [('x', float), ('y', float), ('z', float)])
Point = make_dataclass('P
OTOH daytaclass is a decorator for *better* metaclass compatibility.
On Dec 10, 2017 13:17, "Antoine Pitrou" wrote:
> On Sun, 10 Dec 2017 20:47:45 +0100
> Antoine Pitrou wrote:
>
> > Hi,
> >
> > On Sun, 10 Dec 2017 19:17:25 +
> > Tin Tvrtković wrote:
> > > Hello,
> > >
> > > I'm one of the
On Sun, 10 Dec 2017 20:47:45 +0100
Antoine Pitrou wrote:
> Hi,
>
> On Sun, 10 Dec 2017 19:17:25 +
> Tin Tvrtković wrote:
> > Hello,
> >
> > I'm one of the attrs contributors, and the person who initially wrote the
> > slots functionality there.
> >
> > We've given up on returning a new cl
While the note from a technical standpoint is interest, Xavier, I don't
quite see what needs to be done to support Android at this point. Are you
simply asking we add Android API 24 as an official platform? Or permission
to add your note to the Misc/ directory? Basically what are you wanting to
see
Hi,
On Sun, 10 Dec 2017 19:17:25 +
Tin Tvrtković wrote:
> Hello,
>
> I'm one of the attrs contributors, and the person who initially wrote the
> slots functionality there.
>
> We've given up on returning a new class always since this can conflict with
> certain metaclasses (have you notice
Hello,
I'm one of the attrs contributors, and the person who initially wrote the
slots functionality there.
We've given up on returning a new class always since this can conflict with
certain metaclasses (have you noticed you can't make a slots attrs class
inheriting from Generic[T]?) and with PE
On Dec 9, 2017 8:53 PM, "INADA Naoki" wrote:
> Earlier versions of PEP 538 thus included "en_US.UTF-8" on the
> candidate target locale list, but that turned out to cause assorted
> problems due to the "C -> en_US" part of the coercion.
Hm, but PEP 538 says:
> this PEP instead proposes to exten
2017-12-10 18:46 GMT+01:00 INADA Naoki :
> Except one typo I commented on Github,
Fixed:
https://github.com/python/peps/commit/08224bf6bdf16b539fb6f8136061877e5924476d
> I accept PEP 540.
Wow, thank you :-) Again, thank you for your very useful feedback
which helped to make the PEP 540 much bet
Except one typo I commented on Github,
I accept PEP 540.
Well done, Victor and Nick for PEP 540 and 538.
Python 3.7 will be most UTF-8 friendly Python 3 than ever.
INADA Naoki
On Mon, Dec 11, 2017 at 2:21 AM, Victor Stinner
wrote:
> Ok, I fixed the effects of the locale coercion (PEP 538). D
Ok, I fixed the effects of the locale coercion (PEP 538). Does it now
look good to you, Naoki?
https://www.python.org/dev/peps/pep-0540/#relationship-with-the-locale-coercion-pep-538
The commit:
https://github.com/python/peps/commit/71cda51fbb622ece63f7a9d3c8fa6cd33ce06b58
diff --git a/pep-0540
The following note is a proposal to add the support of the Android platform.
The note is easier to read with clickable links at
https://github.com/xdegaye/cagibi/blob/master/doc/android_support.rst
Motivations
===
* Android is ubiquitous.
* This would be the first platform supported by
Hi,
Le 10 déc. 2017 05:48, "INADA Naoki" a écrit :
Now I'm OK to accept the PEP, except one nitpick.
I got a private email about the same issue. I don't think that it's
nitpicking since many people were confused about the relationship between
the PEP 538 and PEP 540. So it seems like I was con
27 matches
Mail list logo
