Hi,
Thank you all for your time.
In fact I'm really a newbie and I need to study so hard (including English) to
become someone like you all. I don't know if is possible, but I need to try.
Once again, thank you all for your time and I'm sorry if I'm bother both of you.
Kind regards,
Wagner
Cool, thanks! I'm curious why this was brought up at all then...
On Dec 15, 2017 3:36 PM, "Raymond Hettinger"
wrote:
>
>
> > On Dec 15, 2017, at 1:47 PM, Guido van Rossum wrote:
> >
> > On Fri, Dec 15, 2017 at 12:45 PM, Raymond Hettinger <
> raymond.hettin...@gmail.com> wrote:
> >
> > > On Dec
> On Dec 15, 2017, at 1:47 PM, Guido van Rossum wrote:
>
> On Fri, Dec 15, 2017 at 12:45 PM, Raymond Hettinger
> wrote:
>
> > On Dec 15, 2017, at 7:53 AM, Guido van Rossum wrote:
> >
> > Make it so. "Dict keeps insertion order" is the ruling.
>
> On Twitter, someone raised an interesting q
16.12.17 00:48, Ivan Levkivskyi пише:
Actually documentation
https://docs.python.org/3.6/reference/datamodel.html#customizing-class-creation
already says `classmethod object.__init_subclass__(cls)`
I am not an expert in this, so I am not sure if the docs can be improved
here (maybe we can add h
On 15 December 2017 at 19:35, Serhiy Storchaka wrote:
> 15.12.17 20:02, Yury Selivanov пише:
>
>> But nobody decorates __new__ with a @staticmethod. And making
>> __class_getitem__ a @classmethod will only confuse users -- that's all
>> I'm saying.
>>
>> So I'm +1 to keep the things exactly as t
On 15 December 2017 at 18:40, Serhiy Storchaka wrote:
> 15.12.17 19:04, Ivan Levkivskyi пише:
>
>> Good point! Pure Python will be the primary use case and we have another
>> precedent
>> for "automatic" class method: __init_subclass__ (it does not need to be
>> decorated).
>>
>
> __init_subclass
On Fri, Dec 15, 2017 at 12:45 PM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
>
> > On Dec 15, 2017, at 7:53 AM, Guido van Rossum wrote:
> >
> > Make it so. "Dict keeps insertion order" is the ruling.
>
> On Twitter, someone raised an interesting question.
>
> Is the guarantee just fo
On 15 December 2017 at 20:07, Chris Barker wrote:
> And if I understand the rest of the PEP, while typing itself is optional,
> the use of type Annotation is not -- it is exactly what's being used to
> generate the fields the user wants.
>
> And the examples are all using typing -- granted, primar
Hi,
2017-12-15 20:55 GMT+01:00 Barry Warsaw :
> I haven’t bisected this yet, but with git head, built and tested on macOS
> 10.12.6 and Xcode 9.2, I’m seeing this crash in test_embed:
>
> ==
> FAIL: test_bpo20891 (test.test_embed
On Fri, Dec 15, 2017 at 9:39 AM, Mariatta Wijaya
wrote:
> I agree it's useful info :)
>
> I went ahead and made a PR [1].
>
Thanks! I added a couple comments to that PR.
> Not sure about updating PEP 498 at this point..
>
A little clarification text would be nice. I made a PR for that:
https
> On Dec 15, 2017, at 7:53 AM, Guido van Rossum wrote:
>
> Make it so. "Dict keeps insertion order" is the ruling.
On Twitter, someone raised an interesting question.
Is the guarantee just for 3.7 and later? Or will the blessing also cover 3.6
where it is already true.
The 3.6 guidance is
On Dec 15, 2017 10:50, "Tim Peters" wrote:
[Eric Snow ]
> Does that include preserving order after deletion?
Given that we're blessing current behavior:
- At any moment, iteration order is from oldest to newest. So, "yes"
to your question.
- While iteration starts with the oldest, .popitem()
On Dec 15, 2017, at 15:14, Raymond Hettinger
wrote:
>
> I saw this same test failure. After a "make distclean", it went away.
Dang, not for me.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@p
> On Dec 15, 2017, at 11:55 AM, Barry Warsaw wrote:
>
> I haven’t bisected this yet, but with git head, built and tested on macOS
> 10.12.6 and Xcode 9.2, I’m seeing this crash in test_embed:
>
> ==
> FAIL: test_bpo20891 (tes
One other note (see my last message).
The PEP should include a summary of the discussion of the decision to use
the type annotation syntax vs other options.
I just looked through all the gitHub issues and found nothing, and started
to look at the python-ideas list archive and got overwhelmed.
So
Sorry about the email mangling -- I do a lot of my listserve work on the
bus on an iPhone, with the built -in mail client -- and it REALLY sucks for
doing interspersed email replying -- highly encouraging the dreaded top
posting...
But anyway, I think both Steve and I were expressing concerns abou
I haven’t bisected this yet, but with git head, built and tested on macOS
10.12.6 and Xcode 9.2, I’m seeing this crash in test_embed:
==
FAIL: test_bpo20891 (test.test_embed.EmbeddingTests)
---
On 2017-12-15 16:36, Antoine Pitrou wrote:
On Fri, 15 Dec 2017 14:05:46 +0200
Serhiy Storchaka wrote:
15.12.17 04:00, Guido van Rossum пише:
> In the light of Antoine's and Stephan's feedback I think this can be
> reconsidered -- while I want to take a cautious stance about resource
> consump
I've used Kivy with buildozer on Android and it generally works well, with a few
issues. Currently it uses the Crystax NDK for Python 3 support.
Does anyone know how this development will affect it?
-Mike
On 2017-12-15 10:06, Glenn Linderman wrote:
I see a variety of Python apps on Android,
[Eric Snow ]
> Does that include preserving order after deletion?
Given that we're blessing current behavior:
- At any moment, iteration order is from oldest to newest. So, "yes"
to your question.
- While iteration starts with the oldest, .popitem() returns the
youngest. This is analogous to h
On Fri, Dec 15, 2017 at 11:35 AM, Serhiy Storchaka wrote:
> In this case I suggest to make __class_getitem__ an automatic class method
> like __init_subclass__.
+1 I was just about to suggest the same thing.
-eric
___
Python-Dev mailing list
Python-De
On Fri, Dec 15, 2017 at 10:30 AM, Eric Snow
wrote:
> On Fri, Dec 15, 2017 at 8:53 AM, Guido van Rossum
> wrote:
> > Make it so. "Dict keeps insertion order" is the ruling. Thanks!
>
> Does that include preserving order after deletion?
Yes, that's what the rest of the thread was about.
--
--G
15.12.17 20:02, Yury Selivanov пише:
But nobody decorates __new__ with a @staticmethod. And making
__class_getitem__ a @classmethod will only confuse users -- that's all
I'm saying.
So I'm +1 to keep the things exactly as they are now. It would be
great do document that in order to implement _
On 12/15/2017 8:29 AM, Xavier de Gaye wrote:
On 12/14/2017 02:59 PM, Victor Stinner wrote:
> It seems like Android is evolving quickly, would say quicker than
> Python releases. I'm asking if it's a good idea to put a recipe aside
> the Python source code for one specific Android API version? Wou
On Fri, Dec 15, 2017 at 8:53 AM, Guido van Rossum wrote:
> Make it so. "Dict keeps insertion order" is the ruling. Thanks!
Does that include preserving order after deletion?
-eric
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.or
On 15 December 2017 at 18:19, Serhiy Storchaka wrote:
> 15.12.17 17:53, Guido van Rossum пише:
>>
>> Make it so. "Dict keeps insertion order" is the ruling. Thanks!
>
> What should dict.popitem() return? The first item, the last item, or
> unspecified?
I'd say leave it as unspecified.
Paul
__
Whatever it does in 3.6.
On Fri, Dec 15, 2017 at 10:19 AM, Serhiy Storchaka
wrote:
> 15.12.17 17:53, Guido van Rossum пише:
>
>> Make it so. "Dict keeps insertion order" is the ruling. Thanks!
>>
>
> What should dict.popitem() return? The first item, the last item, or
> unspecified?
>
>
> __
15.12.17 17:53, Guido van Rossum пише:
Make it so. "Dict keeps insertion order" is the ruling. Thanks!
What should dict.popitem() return? The first item, the last item, or
unspecified?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.
On Fri, Dec 15, 2017 at 12:45 PM, Serhiy Storchaka wrote:
> 15.12.17 18:47, Yury Selivanov пише:
>>
>> Shouldn't we optimize the usability for pure-Python first, and then for C
>> API?
>>
>> Right now we have the '__new__' magic method, which isn't a
>> @classmethod. Making '__class_getitem__' a
On Fri, 15 Dec 2017 19:18:11 +0200
Serhiy Storchaka wrote:
> 15.12.17 18:36, Antoine Pitrou пише:
> > Do you have any general idea how to speed up class creation?
>
> Some work was done in [https://bugs.python.org/issue31336]. Currently I
> have no ideas.
>
> Creating a class is 1-2 orders sl
15.12.17 18:47, Yury Selivanov пише:
Shouldn't we optimize the usability for pure-Python first, and then for C API?
Right now we have the '__new__' magic method, which isn't a
@classmethod. Making '__class_getitem__' a @classmethod will confuse
regular Python users. For example:
class Foo
I agree it's useful info :)
I went ahead and made a PR [1].
In my PR, I simply linked to the Format Specification Mini Language[2] from
f-strings documentation[3].
Not sure about updating PEP 498 at this point..
[1] https://github.com/python/cpython/pull/4888
[2] https://docs.python.org/3.6/lib
15.12.17 19:04, Ivan Levkivskyi пише:
Good point! Pure Python will be the primary use case and we have another
precedent
for "automatic" class method: __init_subclass__ (it does not need to be
decorated).
__init_subclass__ is very different beast, and parallels with it can be
confusing. It is
On 12/15/2017 11:55 AM, Guido van Rossum wrote:
On Fri, Dec 15, 2017 at 8:32 AM, Raymond Hettinger
mailto:raymond.hettin...@gmail.com>> wrote:
> On Dec 15, 2017, at 7:53 AM, Guido van Rossum mailto:gu...@python.org>> wrote:
>
> Make it so. "Dict keeps insertion order" is the ruling
15.12.17 18:36, Antoine Pitrou пише:
Do you have any general idea how to speed up class creation?
Some work was done in [https://bugs.python.org/issue31336]. Currently I
have no ideas.
Creating a class is 1-2 orders slower than creating a function. And
adding parent classes significantly sl
ACTIVITY SUMMARY (2017-12-08 - 2017-12-15)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open6330 (+15)
closed 37755 (+64)
total 44085 (+79)
Open issues wi
On 15 December 2017 at 17:47, Yury Selivanov
wrote:
> Shouldn't we optimize the usability for pure-Python first, and then for C
> API?
>
> Right now we have the '__new__' magic method, which isn't a
> @classmethod. Making '__class_getitem__' a @classmethod will confuse
> regular Python users. F
On Fri, Dec 15, 2017 at 8:32 AM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
>
> > On Dec 15, 2017, at 7:53 AM, Guido van Rossum wrote:
> >
> > Make it so. "Dict keeps insertion order" is the ruling. Thanks!
>
> Thank you. That is wonderful news :-)
>
> Would it be reasonable to repl
That's covered under "format specifiers" I think.
The PEP mentions this:
https://www.python.org/dev/peps/pep-0498/#format-specifiers
I can see how a newbie might not realize that that means that f-strings use
the same formatting language as the .format() method, and or where to find
documentation
Shouldn't we optimize the usability for pure-Python first, and then for C API?
Right now we have the '__new__' magic method, which isn't a
@classmethod. Making '__class_getitem__' a @classmethod will confuse
regular Python users. For example:
class Foo:
def __new__(cls, ...): pass
On Fri, 15 Dec 2017 14:05:46 +0200
Serhiy Storchaka wrote:
> 15.12.17 04:00, Guido van Rossum пише:
> > In the light of Antoine's and Stephan's feedback I think this can be
> > reconsidered -- while I want to take a cautious stance about resource
> > consumption I don't want to stand in the way
> On Dec 15, 2017, at 7:53 AM, Guido van Rossum wrote:
>
> Make it so. "Dict keeps insertion order" is the ruling. Thanks!
Thank you. That is wonderful news :-)
Would it be reasonable to replace some of the OrderedDict() uses in the
standard library with dict()? For example, have namedtuple
On 12/14/2017 02:59 PM, Victor Stinner wrote:
> It seems like Android is evolving quickly, would say quicker than
> Python releases. I'm asking if it's a good idea to put a recipe aside
> the Python source code for one specific Android API version? Would it
> still make sense to build for NDK v14
That's covered under "format specifiers" I think.
The PEP mentions this:
https://www.python.org/dev/peps/pep-0498/#format-specifiers
That specific example is not mentioned in the docs, but there other
examples of using format specifiers with f-strings.
https://docs.python.org/3/reference/lexical_a
Make it so. "Dict keeps insertion order" is the ruling. Thanks!
On Fri, Dec 15, 2017 at 2:30 AM, INADA Naoki wrote:
> > That's interesting information - I wasn't aware of the different
> > performance goals.
>
> FYI, performance characteristic of my POC implementation of
> OrderedDict based on d
Good evening,
I'm Wagner Herculano from Brazil.
I was trying to do a table exercise with number 5 and tried formatting spaces
and did not find it in PEP 498 documentation.
Finally I found a way, if possible, include this example in the documentation
please.
Below is my script with the desired fo
I like this idea. I have few suggestions for the test cases you added, will
add them a bit later in the PR.
--
Ivan
On 15 December 2017 at 16:00, Serhiy Storchaka wrote:
> The class itself always is passed as the first argument to
> __class_getitem__():
>
> cls.__class_getitem__(cls, item)
On 15 December 2017 at 15:55, Yury Selivanov
wrote:
> > I don't see any problems with implementing this on types defined in C.
> This isn't harder than implementing __sizeof__ or pickling support, and
> NumPy classes already have implemented both. Maybe Yury forgot about
> METH_STATIC and METH_CL
The class itself always is passed as the first argument to
__class_getitem__():
cls.__class_getitem__(cls, item)
I propose to make __class_getitem__ a class method. This will make
simpler implementing it in C. Currently it should be declared with flags
METH_VARARGS|METH_STATIC and impleme
> I don't see any problems with implementing this on types defined in C. This
> isn't harder than implementing __sizeof__ or pickling support, and NumPy
> classes already have implemented both. Maybe Yury forgot about METH_STATIC
> and METH_CLASS?
I just tested __class_getitem__ defined via MET
15.12.17 04:00, Guido van Rossum пише:
In the light of Antoine's and Stephan's feedback I think this can be
reconsidered -- while I want to take a cautious stance about resource
consumption I don't want to stand in the way of progress.
I don't see any problems with implementing this on types d
On 12/15/2017 5:56 AM, Steve Holden wrote:
On Mon, Dec 11, 2017 at 5:10 PM, Chris Barker - NOAA Federal
mailto:chris.bar...@noaa.gov>> wrote:
...
However, typing is not currently imported by dataclasses.py.
>
And there you have an actual reason besides my uneasiness :-)
- CHB
hmm..
I'm not sure what Mail User Agent each of you is using, but it is quite
impossible (here) to make out who is saying what in your latest
messages.
See plain text rendering here:
https://mail.python.org/pipermail/python-dev/2017-December/151274.html
Regards
Antoine.
On Fri, 15 Dec 2017 10:56:28
On Mon, Dec 11, 2017 at 5:10 PM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:
> .
>
> I see a couple of options:
> 1a: Use a default type annotation, if one is not is supplied. typing.Any
> would presumably make the most sense.
> 1b: Use None if not type is supplied.
> 2: Rework the
> That's interesting information - I wasn't aware of the different
> performance goals.
FYI, performance characteristic of my POC implementation of
OrderedDict based on dict order are:
* 50% less memory usage
* 15% faster creation
* 100% (2x) faster iteration
* 20% slower move_to_end
* 40% slower
On 15 December 2017 at 05:28, Raymond Hettinger
wrote:
> In contrast, I gave collections.OrderedDict a different design (later coded
> in C by Eric Snow). The primary goal was to have efficient maintenance of
> order even for severe workloads such at that imposed by the lru_cache which
> frequ
15.12.17 02:33, Antoine Pitrou пише:
On Thu, 14 Dec 2017 16:03:48 -0800
Guido van Rossum wrote:
A slot is pretty expensive, as *every* class in existence will be another 8
bytes larger (and possibly more due to malloc rounding).
I'm always surprised by the discussions about class object size.
57 matches
Mail list logo
