Re: [Python-Dev] Emit SyntaxWarning on unrecognized backslash escapes?

2015-02-24 Thread Joao S. O. Bueno
On 23 February 2015 at 18:39, Greg Ewing  wrote:
> Serhiy Storchaka wrote:
>>
>> The problem is that the user don't know that he should read the
>> documentation. It just find that his script works with "C:\sample.txt", but
>> doesn't work with "D:\test.txt". He has no ideas what happen.
>
>
> Even with the syntax error, there are filenames that
> will mysteriously fail, e.g. "C:\ninjamoves.txt".


That is the reason I urge folks to think about the root cause,
and check if this proposal is the best way to tackle it:
The failing cases are the ones that won't be affected by this change at all -
as they are valid escaped strings!

There will be no error for
c:\tmp\myfile.txt - it will ever be just "file not found" - unless the
warning comes to
using "\" as file path separator (and no, I don  think just doing that
would properly
address the issue as well).

Could we just use Guido's time machine and go back to the point in time where
some MS head decided to go with "\" instead of "/", and deliver a well
placed punch? :-)

Or maybe have IOError for "file not found" to get some fuzzy logic and
display a more verbose error message if there are "\n"s and "\t"s on
the filename
and platform is Windows?  I think that  could go along the proposal for
deprecating non-escaping "\" sequences .

By the way,  although I am writing to get the root issue covered, I think
deprecating them would be a good thing, yes. Despite my previous comment
on deprecating code that works, on a deeper though it _is_ worth the issue.

  js
 -><-



>
> --
> Greg
>
> ___
> 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/jsbueno%40python.org.br
___
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] Why aren't decorators just expressions?

2017-09-19 Thread Joao S. O. Bueno
I myself found out abotu this restriction once I clashesd into it-
soit was one time
the restriction bit me back.
But I can't remember if that was for intended production code or for
toying around
either.

Anyway, a simple "nop" function can allow for any arbitrary expression
to be used
as decorator, at expense of a little more line noise. And the
restriction prevents the line
noise to emerge as "cool" in some framework that mitg take inspiration
in trends ongoing
in other languages.

nop = lambda f: f

@nop(MyClass(things)[dimension1, dimension2[subdimension5]] +
CombinableAutoMixinDecoFactory())
def my_func(): pass



On 18 September 2017 at 18:33, Éric Araujo  wrote:
>   Hello,
>
> Le 2017-09-16 à 07:22, Serhiy Storchaka a écrit :
>> 16.09.17 12:39, Larry Hastings пише:
>>> So why don't decorators allow arbitrary expressions?  [...]
>>
>> Actually I remember somebody raised this question a year or two ago,> but 
>> don't remember details.
>
>   The discussion I remember was https://bugs.python.org/issue19660
>
>   Guido said: «Nobody has posted a real use case. All the examples are
> toys. What are the real use cases that are blocked by this? Readability
> counts!»
>
>   Cheers
> ___
> 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/jsbueno%40python.org.br
___
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] Reminder: 12 weeks to 3.7 feature code cutoff

2017-11-03 Thread Joao S. O. Bueno
This just popped up in Brython's issue tracker discussion:

"""
Pierre Quentel 

04:57 (16 hours ago)
to brython-dev/br., Subscribed

I think it's better to rename all occurences of async now, although
it's strange that :

there is currently no deprecation warning in CPython with code that
uses it as a variable name, PEP492 said that "async and await names
will be softly deprecated in CPython 3.5 and 3.6"
there is no mention of async and await becoming keywords in What's new
in Python 3.7

Maybe the idea was finally given up, but I can't find a reference.

"""

So, what is the status of promoting async and await to full keyword for 3.7?


On 1 November 2017 at 19:47, Ned Deily  wrote:
> Happy belated Halloween to those who celebrate it; I hope it wasn't too 
> scary!  Also possibly scary: we have just a little over 12 weeks remaining 
> until Python 3.7's feature code cutoff, 2018-01-29.  Those 12 weeks include a 
> number of traditional holidays around the world so, if you are planning on 
> writing another PEP for 3.7 or working on getting an existing one approved or 
> getting feature code reviewed, please plan accordingly.If you have 
> something in the pipeline, please either let me know or, when implemented, 
> add the feature to PEP 537, the 3.7 Release Schedule PEP.  As you may recall, 
> the release schedule calls for 4 alpha preview releases prior to the feature 
> code cutoff with the first beta release.  We have already produced the first 
> two alphas.  Reviewing the schedule recently, I realized that I had 
> "front-loaded" the alphas, leaving a bigger gap between the final alphas and 
> the first beta.  So I have adjusted the schedule a bit, pushing alpha 3 and 4 
> out.  The new
  d
>  ates are:
>
> - 3.7.0 alpha 3: 2017-11-27 (was 2017-11-13)
> - 3.7.0 alpha 4: 2018-01-08 (was 2017-12-18)
> - 3.7.0 beta 1:  2018-01-29 (feature freeze - unchanged)
>
> I hope the new dates give you a little bit more time to get your bits 
> finished and get a little bit of exposure prior to the feature freeze.
>
> Considering how quickly and positively it has been adopted, 3.6 is going to 
> be a tough act to follow.  But we can do it again.  Thank you all for your 
> ongoing efforts!
>
> --Ned
>
> --
>   Ned Deily
>   n...@python.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/jsbueno%40python.org.br
___
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] Guarantee ordered dict literals in v3.7?

2017-11-06 Thread Joao S. O. Bueno
On 6 November 2017 at 17:23, Paul G  wrote:
> Is there a major objection to just adding in explicit syntax for 
> order-preserving dictionaries? To some extent that seems like a reasonable 
> compromise position in an "explicit is better than implicit" sense. A whole 
> lot of code is out there that doesn't require or expect order-preserving 
> dictionaries - it would be nice to be able to differentiate out the parts 
> where order actually *does* matter.
>
> (Of course, given that CPython's implementation is order-preserving, a bunch 
> of code is probably now being written that implicitly requires on this 
> detail, but at least having syntax that makes that clear would give people 
> the *option* to make the assumption explicit).

I think the additional syntax have the added benefit of preventing
code that relies on the ordering of dict literals to be run on older
versions, therefore triggering subtle bugs that had already being
mentioned.

And also, forgot along the discussion, is the big disadvantage that
other Python implementations would have a quite
significant overhead on mandatory ordered dicts. One that was
mentioned along the way is transpilers, with
Brython as an example - but there might be others. MircoPython is far
from being the only implementation affected.

  js
-><-

>
> On 11/06/2017 01:19 PM, Barry Warsaw wrote:
>> On Nov 6, 2017, at 02:18, Paul Sokolovsky  wrote:
>>
>>> What it will lead to is further fragmentation of the community. Python2
>>> vs Python3 split is far from being over, and now there're splits
>>> between:
>>>
>>> * people who use "yield from" vs "await"
>>> * people who use f-strings vs who don't
>>> * people who rely on sorted nature of dict's vs who don't
>>
>> This is the classic argument of, do you proceed conservatively and use the 
>> lowest-common denominator that makes your code work with the widest range of 
>> versions, or do you ride the wave and adopt the latest and greatest features 
>> as soon as they’re available?
>>
>> Neither answer is wrong or right… for everyone.  It’s also a debate as old 
>> as the software industry. Every package, project, company, developer, 
>> community will have to decide for themselves.  Once you realize you can’t 
>> win, you’ve won! :)
>>
>> -Barry
>>
>>
>>
>> ___
>> 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/paul%40ganssle.io
>>
>
>
> ___
> 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/jsbueno%40python.org.br
>
___
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] Proposal: go back to enabling DeprecationWarning by default

2017-11-07 Thread Joao S. O. Bueno
On 6 November 2017 at 05:09, Guido van Rossum  wrote:
> I still find this unfriendly to users of Python scripts and small apps who
> are not the developers of those scripts. (Large apps tend to spit out so
> much logging it doesn't really matter.)
>
> Isn't there a better heuristic we can come up with so that the warnings tend
> to be on for developers but off for end users?
>
> --
> --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/jsbueno%40python.org.br
>
___
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] Proposal: go back to enabling DeprecationWarning by default

2017-11-07 Thread Joao S. O. Bueno
Sorry - trigger happy on the previous message.

On 6 November 2017 at 05:09, Guido van Rossum  wrote:
> I still find this unfriendly to users of Python scripts and small apps who
> are not the developers of those scripts. (Large apps tend to spit out so
> much logging it doesn't really matter.)
>
> Isn't there a better heuristic we can come up with so that the warnings tend
> to be on for developers but off for end users?

So, I don't know who is the "Jose Bueno" mentioned in the first message - :-)
I just conveyed a concern from the Brython developers, as I follow the
project -
and I'd rather have my terminal clean when using programs.

Making some thing when one does "python setup.py  develop" to flip the
switches so
that the deprecation warnings get turned on might be a nice idea, and
overall help people, tough.

  joao bueno
  -><-
>
> --
> --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/jsbueno%40python.org.br
>
___
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] Analog of PEP 448 for dicts (unpacking in assignment with dict rhs)

2017-11-11 Thread Joao S. O. Bueno
Ben, I have a small package which enables one to do:

with MapGetter(my_dictionary):
from my_dictionary import a, b, parameter3

If this interests you, contributions so it can get hardenned for
mainstram acceptance are welcome.
https://github.com/jsbueno/extradict

On 11 November 2017 at 04:26, Ben Usman  wrote:
> Got it, thank you. I'll go and check it out!
>
> On Nov 11, 2017 01:22, "Jelle Zijlstra"  wrote:
>>
>>
>>
>> 2017-11-10 19:53 GMT-08:00 Ben Usman :
>>>
>>> The following works now:
>>>
>>> seq = [1, 2]
>>> d = {'c': 3, 'a': 1, 'b': 2}
>>>
>>> (el1, el2) = *seq
>>> el1, el2 = *seq
>>> head, *tail = *seq
>>>
>>> seq_new = (*seq, *tail)
>>> dict_new = {**d, **{'c': 4}}
>>>
>>> def f(arg1, arg2, a, b, c):
>>> pass
>>>
>>> f(*seq, **d)
>>>
>>> It seems like dict unpacking syntax would not be fully coherent with
>>> list unpacking syntax without something like:
>>>
>>> {b, a, **other} = **d
>>>
>>> Because iterables have both syntax for function call unpacking and
>>> "rhs in assignment unpacking" and dict has only function call
>>> unpacking syntax.
>>>
>>> I was not able to find any PEPs that suggest this (search keywords:
>>> "PEP 445 dicts", "dictionary unpacking assignment", checked PEP-0),
>>> however, let me know if I am wrong.
>>>
>> It was discussed at great length on Python-ideas about a year ago. There
>> is a thread called "Unpacking a dict" from May 2016.
>>
>>>
>>> The main use-case, in my understating, is getting shortcuts to
>>> elements of a dictionary if they are going to be used more then
>>> ones later in the scope. A made-up example is using a config to
>>> initiate a bunch of things with many config arguments with long
>>> names that have overlap in keywords used in initialization.
>>>
>>> One should either write long calls like
>>>
>>> start_a(config['parameter1'], config['parameter2'],
>>> config['parameter3'], config['parameter4'])
>>>
>>> start_b(config['parameter3'], config['parameter2'],
>>> config['parameter3'], config['parameter4'])
>>>
>>> many times or use a list-comprehension solution mentioned above.
>>>
>>> It becomes even worse (in terms of readability) with nested structures.
>>>
>>> start_b(config['group2']['parameter3'], config['parameter2'],
>>> config['parameter3'], config['group2']['parameter3'])
>>>
>>>
>>> ## Rationale
>>>
>>> Right now this problem is often solved using [list] comprehensions,
>>> but this is somewhat verbose:
>>>
>>> a, b = (d[k] for k in ['a', 'b'])
>>>
>>> or direct per-instance assignment (looks simple for with
>>> single-character keys, but often becomes very verbose with
>>> real-world long key names)
>>>
>>> a = d['a']
>>> b = d['b']
>>>
>>> Alternatively one could have a very basic method\function
>>> get_n() or __getitem__() accepting more then a single argument
>>>
>>> a, b = d.get_n('a', 'b')
>>> a, b = get_n(d, 'a', 'b')
>>> a, b = d['a', 'b']
>>>
>>> All these approaches require verbose double-mentioning of same
>>> key. It becomes even worse if you have nested structures
>>> of dictionaries.
>>>
>>> ## Concerns and questions:
>>>
>>> 0. This is the most troubling part,  imho, other questions
>>> are more like common thoughts. It seems (to put it mildly)
>>> weird that execution flow depends on names of local variables.
>>>
>>> For example, one can not easily refactor these variable names. However,
>>> same is true for dictionary keys anyway: you can not suddenly decide
>>> and refactor your code to expect dictionaries with keys 'c' and
>>> 'd' whereas your entire system still expects you to use dictionaries
>>> with keys 'a' and 'b'. A counter-objection is that this specific
>>> scenario is usually handled with record\struct-like classes  with
>>> fixed members rather then dicts, so this is not an issue.
>>>
>>> Quite a few languages (closure and javascript to name a few) seem
>>> to have this feature now and it seems like they did not suffer too
>>> much from refactoring hell. This does not mean that their approach
>>> is good, just that it is "manageable".
>>>
>>> 1. This line seems coherent with sequence syntax, but redundant:
>>> {b, a, **other} = **d
>>>
>>> and the following use of "throwaway" variable just looks poor visually
>>> {b, a, **_} = **d
>>>
>>> could it be less verbose like this
>>> {b, a} = **d
>>>
>>> but it is not very coherent with lists behavior.
>>>
>>> E.g. what if that line did not raise something like "ValueError:
>>> Too many keys to unpack, got an unexpected keyword argument 'c'".
>>>
>>> 2. Unpacking in other contexts
>>>
>>> {self.a, b, **other} = **d
>>>
>>> should it be interpreted as
>>> self.a, b = d['a'], d['b']
>>>
>>> or
>>>
>>> self.a, b = d['self.a'], d['b']
>>>
>>> probably the first, but what I am saying is that these name-extracting
>>> rules should be strictly specified and it might not be trivial.
>>>
>>> ---
>>> Ben
>>>
>>> ___
>>> Python-Dev mailing list
>>> Python-Dev@python.org
>>> https://mail.python.org/mailman/listinfo/python-dev

Re: [Python-Dev] Analog of PEP 448 for dicts (unpacking in assignment with dict rhs)

2017-11-11 Thread Joao S. O. Bueno
On 11 November 2017 at 23:40, Koos Zevenhoven  wrote:
> Oops, forgot to reply to the list.
>
>
> On Nov 12, 2017 03:35, "Koos Zevenhoven"  wrote:
>
> On Nov 12, 2017 02:12, "Joao S. O. Bueno"  wrote:
>
> Ben, I have a small package which enables one to do:
>
> with MapGetter(my_dictionary):
> from my_dictionary import a, b, parameter3
>
> If this interests you, contributions so it can get hardenned for
> mainstram acceptance are welcome.
> https://github.com/jsbueno/extradict
>
>
> Your VersionDict in fact has some similarities to what I have thought of
> implementing using the PEP 555 machinery, but it is also a bit different.
> Interesting...
>

My main issue with that VersionDict is that after I did it, I didn't
had a real case
where to use it. So, it never been used beyond the unit tests and some
playing around.
(I wrote it when dicts in Python got versioning and that was only
visible from the C-API)

I remember the idea for the versioned value retrieved occurred to me
quite naturally when I wrote it,
so it is probably close to the "OOWTDI".



> -- Koos (mobile)
>
>
___
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] What's the status of PEP 505: None-aware operators?

2017-11-29 Thread Joao S. O. Bueno
On 28 November 2017 at 18:38, Barry Warsaw  wrote:
> On Nov 28, 2017, at 15:31, Raymond Hettinger  
> wrote:
>
>> Put me down for a strong -1.   The proposal would occasionally save a few 
>> keystokes but comes at the expense of giving Python a more Perlish look and 
>> a more arcane feel.
>
> I am also -1.
>
>> One of the things I like about Python is that I can walk non-programmers 
>> through the code and explain what it does.  The examples in PEP 505 look 
>> like a step in the wrong direction.  They don't "look like Python" and make 
>> me feel like I have to decrypt the code to figure-out what it does.
>
> I had occasional to speak with someone very involved in Rust development.  
> They have a process roughly similar to our PEPs.  One of the things he told 
> me, which I found very interesting and have been mulling over for PEPs is, 
> they require a section in their specification discussion how any new feature 
> will be taught, both to new Rust programmers and experienced ones.  I love 
> the emphasis on teachability.  Sometimes I really miss that when considering 
> some of the PEPs and the features they introduce (look how hard it is to 
> teach asynchronous programming).

Oh well,
I would be  +1 on patching PEP 1 for that.


>
> Cheers,
> -Barry
>
___
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] The `for y in [x]` idiom in comprehensions

2018-02-22 Thread Joao S. O. Bueno
This thing has bitten me in the past -

At the time I put together the "stackfull" package -

if allows stuff like:

from stackfull import push, pop
...
 [push(f(x)) + g(pop()) for x in range(10)]


It is painfully simple in its workings: it creates a plain old list in
the fame f_locals and uses
that as a stack in all stackfull.* operations.

Just posting because people involved in this thread might want to
experiment with that.
(it is on pypi)

   js
 -><-



On 22 February 2018 at 16:04, Serhiy Storchaka  wrote:
> Yet one discussion about reusing common subexpressions in comprehensions
> took place last week on the Python-ideas maillist (see topic "Temporary
> variables in comprehensions" [1]). The problem is that in comprehension like
> `[f(x) + g(f(x)) for x in range(10)]` the subexpression `f(x)` is evaluated
> twice. In normal loop you can introduce a temporary variable for `f(x)`. The
> OP wanted to add a special syntax for introducing temporary variables in
> comprehensions. This idea already was discussed multiple times in the past.
>
> There are several ways of resolving this problem with existing syntax.
>
> 1. Inner generator expression:
>
> result = [y + g(y) for y in (f(x) for x in range(10))]
>
> 2. The same, but with extracting the inner generator expression as a
> variable:
>
> f_samples = (f(x) for x in range(10))
> result = [y+g(y) for y in f_samples]
>
> 3. Extracting the expression with repeated subexpressions as a function with
> local variables:
>
> def func(x):
> y = f(x)
> return y + g(y)
> result = [func(x) for x in range(10)]
>
> 4. Implementing the whole comprehension as a generator function:
>
> def gen():
> for x in range(10):
> y = f(x)
> yield y + g(y)
> result = list(gen())
>
> 5. Using a normal loop instead of a comprehension:
>
> result = []
> for x in range(10):
> y = f(x)
> result.append(y + g(y))
>
> And maybe there are other ways.
>
> Stephan Houben proposed an idiom which looks similar to new hypothetic
> syntax:
>
> result = [y + g(y) for x in range(10) for y in [f(x)]]
>
> `for y in [expr]` in a comprehension means just assigning expr to y. I never
> seen this idiom before, but it can be a good replacement for a hypothetic
> syntax for assignment in comprehensions. It changes the original
> comprehension less than other approaches, just adds yet one element in a
> sequence of for-s and if-s. I think that after using it more widely it will
> become pretty idiomatic.
>
> I have created a patch that optimizes this idiom, making it as fast as a
> normal assignment. [2] Yury suggested to ask Guido on the mailing list if he
> agrees that this language patten is worth optimizing/promoting.
>
> [1] https://mail.python.org/pipermail/python-ideas/2018-February/048971.html
> [2] https://bugs.python.org/issue32856
>
> ___
> 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/jsbueno%40python.org.br
___
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] How can we use 48bit pointer safely?

2018-03-30 Thread Joao S. O. Bueno
Not only that, but afaik  Linux could simply raise that 57bit virtual
to 64bit virtual without previous
warning on any version change.

On 30 March 2018 at 08:55, Ronald Oussoren  wrote:
>
>
> On Mar 30, 2018, at 08:31 AM, INADA Naoki  wrote:
>
> Hi,
>
> As far as I know, most amd64 and arm64 systems use only 48bit address
> spaces.
> (except [1])
>
> [1]
> https://software.intel.com/sites/default/files/managed/2b/80/5-level_paging_white_paper.pdf
>
> It means there are some chance to compact some data structures.
> I point two examples below.
>
> My question is; can we use 48bit pointer safely?
>
>
> Not really, at least some CPUs can also address more memory than that. See
>  which talks about Linux support for
> 57-bit virtual addresses and 52-bit physical addresses.
>
> Ronald
>
>
> ___
> 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/jsbueno%40python.org.br
>
___
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] Possible undefined behavior on creating a method named "__dict__"

2018-04-11 Thread Joao S. O. Bueno
I just came across a code snippet that
would define a method with the "__dict__" name  - like in:

class A:
def __dict__(self):
 return ()

The resulting class's instances can be assigned
dynamic attributes as usual, but one can never acess
its actual local variables through instance.__dict__ -
the method is retrieved instead.  Calling "vars" will also fail
on objects of this class.

This behavior is weird, and I believe is actually a side-effect
of implementation details on CPython.

I am not sure whether it shoud just:
1 - be left as is - whoever reuses __dict__ as a method had it coming
2 - document  CPythn behavior
3 - file that as a bug to disallow __dict__ override in class declaration
4 - file that as a bug to not-create class __dict__ when one is explictly
  created in Python code (the same that happens when one have "__slots__".

I have the feeling that (1) is just good - but then, I am at least
posting this e-mail here.

Similar weird things go when one creates a method named "__class__",
and possible other names.

(I just checked that pypy3 mimics the behavior)

   js
 -><-
___
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] Slow down...

2018-05-07 Thread Joao S. O. Bueno
May it is important to note that
Python 3.7 already has very little syntactic changes.
Actually, there are no new syntac changes with PEP 563 -
(Postponed Evaluation of Annotations) being maybe
the only change to existing behavior, and PEP 562 as new
"non-library-dependent"  feature, even though no new syntax is
added. (contextvars - PEP 567 - is a big change, but is constrained to
a new stdlib module).

On the other hand, one of the hottest topics being discussed now
 - PEP 572 - would be quite a change that would violate such a
moratorium. What would happen if we wd'd take such a  moratorium now?
 Have Python with no real syntactic changes since f-strings up to version
3.9 (~4.5 years after 3.6)? Allow just whatever is already being discussed
 - introducing a major change (local assignments) in 3.8, but just bar
others because people did not think of then before this moratorium
 was proposed?

Maybe simply there is just no need for such a moratorium mechanism,
and the natural barriers for new features can work to keep
things in manageable pace, as we can see by the release getting
 ready right now.

best regards,

  js
 -><-

On 7 May 2018 at 10:20, Serhiy Storchaka  wrote:
> 07.05.18 14:19, Nick Coghlan пише:
>>
>> And as the current python-ideas discussion about accessing paths relative
>> to __file__ shows,
>
>
> I can't believe this is discussed seriously. Forgot about the Python 2
> legacy, just use importlib.
>
>
> ___
> 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/jsbueno%40python.org.br
___
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 447 (type.__getdescriptor__)

2015-07-23 Thread Joao S. O. Bueno
On 22 July 2015 at 14:21, Ronald Oussoren  wrote:
>>
>> 2. Is this useful, that you can think of, for anything other than connecting 
>> to Objective C?
>
> Not immediately.  But then again, I initially thought that decorators would 
> have limited appeal as well :-).  I guess this could be useful for other 
> proxy-like objects as well, especially when preloading the __dict__ is 
> relatively expensive.
>

I think one place this could be immediately useful is in code using
remote method invocation/remote attribute access. This allows one to
subclass proxy types for remote objects, and call methods that resolve
remotely in a seamless way.
(And without having to download and pre-populate an entire API into
the proxy-class __dict__)

+1
I found the solution rather concise for the flexibility it adds as well.
> Apart from direct usefulness this closes a hole in the way you can influence 
> attribute lookup.
>
> Ronald
___
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] Yet another "A better story for multi-core Python" comment

2015-09-08 Thread Joao S. O. Bueno
Maybe you just have a job for Cap'n'proto?
https://capnproto.org/

On 8 September 2015 at 11:12, Gary Robinson  wrote:
> Folks,
>
> If it’s out of line in some way for me to make this comment on this list, let 
> me know and I’ll stop! But I do feel strongly about one issue and think it’s 
> worth mentioning, so here goes.
>
> I read the "A better story for multi-core Python” with great interest because 
> the GIL has actually been a major hindrance to me. I know that for many uses, 
> it’s a non-issue. But it was for me.
>
> My situation was that I had a huge (technically mutable, but unchanging) data 
> structure which needed a lot of analysis. CPU time was a major factor — 
> things took days to run. But even so, my time as a programmer was much more 
> important than CPU time. I needed to prototype different algorithms very 
> quickly. Even Cython would have slowed me down too much. Also, I had a lot of 
> reason to want to make use of the many great statistical functions in SciPy, 
> so Python was an excellent choice for me in that way.
>
> So, even though pure Python might not be the right choice for this program in 
> a production environment, it was the right choice for me at the time. And, if 
> I could have accessed as many cores as I wanted, it may have been good enough 
> in production too. But my work was hampered by one thing:
>
> There was a huge data structure that all the analysis needed to access. Using 
> a database would have slowed things down too much. Ideally, I needed to 
> access this same structure from many cores at once. On a Power8 system, for 
> example, with its larger number of cores, performance may well have been good 
> enough for production. In any case, my experimentation and prototyping would 
> have gone more quickly with more cores.
>
> But this data structure was simply too big. Replicating it in different 
> processes used memory far too quickly and was the limiting factor on the 
> number of cores I could use. (I could fork with the big data structure 
> already in memory, but copy-on-write issues due to reference counting caused 
> multiple copies to exist anyway.)
>
> So, one thing I am hoping comes out of any effort in the “A better story” 
> direction would be a way to share large data structures between processes. 
> Two possible solutions:
>
> 1) More the reference counts away from data structures, so copy-on-write 
> isn’t an issue. That sounds like a lot of work — I have no idea whether it’s 
> practical. It has been mentioned in the “A better story” discussion, but I 
> wanted to bring it up again in the context of my specific use-case. Also, it 
> seems worth reiterating that even though copy-on-write forking is a Unix 
> thing, the midipix project appears to bring it to Windows as well. 
> (http://midipix.org)
>
> 2) Have a mode where a particular data structure is not reference counted or 
> garbage collected. The programmer would be entirely responsible for manually 
> calling del on the structure if he wants to free that memory. I would imagine 
> this would be controversial because Python is currently designed in a very 
> different way. However, I see no actual risk if one were to use an 
> @manual_memory_management decorator or some technique like that to make it 
> very clear that the programmer is taking responsibility. I.e., in general, 
> information sharing between subinterpreters would occur through message 
> passing. But there would be the option of the programmer taking 
> responsibility of memory management for a particular structure. In my case, 
> the amount of work required for this would have been approximately zero — 
> once the structure was created, it was needed for the lifetime of the process.
>
> Under this second solution, there would be little need to actually remove the 
> reference counts from the data structures — they just wouldn’t be accessed. 
> Maybe it’s not a practical solution, if only because of the overhead of 
> Python needing to check whether a given structure is manually managed or not. 
> In that case, the first solution makes more sense.
>
> In any case I thought this was worth mentioning,  because it has been a real 
> problem for me, and I assume it has been a real problem for other people as 
> well. If a solution is both possible and practical, that would be great.
>
> Thank you for listening,
> Gary
>
>
> --
>
> Gary Robinson
> gary...@me.com
> http://www.garyrobinson.net
>
> ___
> 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/jsbueno%40python.org.br
___
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 0404 and VS 2010

2013-11-20 Thread Joao S. O. Bueno
I'd say publishing a high profile installable code with a "python 2.8" name
would cause a lot of undesired confusion to start with.

I usually lecture on Python to present the language to college students and
I.T. workers - and explaining away the current versioning scheme (use
either 2.7 or 3.3) is hard already. Having to add an explanation about a
downloadable and installable Python 2.8 that would be incompatible with
extensions compiled in Pypi would be tough. and I doubt it could even be
done without making your project look bad on the process.

Can't you just mark it as "visual studio 2010" version instead?

   js
 -><-





On 20 November 2013 18:52, Christian Tismer  wrote:

> Howdy friends,
>
> according to pep 404, there will never be an official Python 2.8.
> The migration path is from 2.7 to 3.x.
>
> I agree with this strategy in almost all consequences but this one:
>
> Many customers are forced to stick with Python 2.X because of other
> products, but they require a Python 2.X version which can be compiled
> using Visual Studio 2010 or better.
> This is considered an improvement and not a bug fix, where I disagree.
>
> So I see many Python 2.7 repositories on BB/GH which are hacked to support
> VS 2010, but they are not converted with the same quality in mind
> that fits our standards.
>
>
> My question
> ---
>
> I have created a very clean Python 2.7.6+ based CPython with the Stackless
> additions, that compiles with VS 2010, using the adapted project structure
> of Python 3.3.X, and I want to publish that on the Stackless website as the
> official "Stackless Python 2.8". If you consider Stackless as official ;-)
> .
>
> This compiler change is currently the only deviation from CPython 2.7,
> but we may support a few easy back-ports on customer demand. We don'd add
> any random stuff, of course.
>
> My question is if that is safe to do:
> Can I rely on PEP 404 that the "Python 2.8" namespace never will clash
> with CPython?
>
> And if not, what do you suggest then?
> It will be submitted by end of November, thanks for your quick responses!
>
> all the best -- Chris
>
> --
> Christian Tismer :^)   
> Software Consulting  : Have a break! Take a ride on Python's
> Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/
> 14482 Potsdam: PGP key -> http://pgp.uni-mainz.de
> phone +49 173 24 18 776  fax +49 (30) 700143-0023
> PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
>   whom do you want to sponsor today?   http://www.stackless.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/
> jsbueno%40python.org.br
>
___
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] Python3 "complexity" (was RFC: PEP 460: Add bytes...)

2014-01-08 Thread Joao S. O. Bueno
On 8 January 2014 20:04, Kristján Valur Jónsson  wrote:
> Believe it or not, sometimes you really don't care about encodings.
> Sometimes you just want to parse text files.  Python 3 forces you to think 
> about abstract concepts like encodings when all you want is to open that .txt 
> file on the drive and extract some phone numbers and merge in some email 
> addresses.  What encoding does the file have?  Do I care?  Must I care?

Kristján, the answer is obviously "yes you must" :-)
___
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] Python3 "complexity"

2014-01-09 Thread Joao S. O. Bueno
On 9 January 2014 04:50, Lennart Regebro  wrote:
> To be honest, you can define text as "A stream of bytes that are split
> up in lines separated by a linefeed", and do some basic text
> processing like that. Just very *basic*, but still. Replacing
> characters. Extracting certain lines etc.

That is, until you hit a character which has a byte with the same
value of ASCII newline in the middle of a multi-byte character.

So, this approach is broken to start with.
___
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] Where is our official policy of what platforms we do support?

2014-05-14 Thread Joao S. O. Bueno
+1 for an official policy that comes with a "permanent maintainer for
this platform required"  as part of the list
of requisites.

  js
 -><-

On 14 May 2014 11:20, Brett Cannon  wrote:
> Over the past week or so there have been 2 patches to add support for
> various UNIX OSs. Now I thought we had stopped trying to add new esoteric
> OSs (e.g. I had never heard of MirOS until the patch for it came in), but I
> can't find a PEP that spells out what it takes to get a platform supported
> (http://legacy.python.org/dev/peps/pep-0011/ is about removing platforms,
> not keeping them or adding them unless you are re-adding one which
> apparently just takes a volunteer).
>
> Do we want an official policy written down in a PEP (yes, I can write it)?
> Should I keep closing these patches and saying that we are not adding
> support for new operating systems and be hand-wavy about it?
>
> ___
> 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/jsbueno%40python.org.br
>
___
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] Re: What to do about invalid escape sequences

2019-08-07 Thread Joao S. O. Bueno
For what I can see, the majority of new users in an interactive environment
seeing the warning will do so because the incorrect string will be
in _their_ code. The benefits are immediate, as people change to either
using raw-strings or using forward-slashes for file paths.

The examples in the beggining of this thread, where one changing
a file path to "C:\users" sudden have broken code speaks for themselves:
this is a _fix_ . Broken libraries will be fixed within weeks of a Py 3.8
release. People
will either be using an old install, with Python 3.7, or they keep
everything up to date,
 and for those after 2 months max, the library warnings will be all but
gone.

In the meantime, what is possible is to publicize more how to disable these
warnings on
end-users side, since we all agree that few people know how to that.

On Wed, 7 Aug 2019 at 06:51, Chris Angelico  wrote:

> On Wed, Aug 7, 2019 at 7:33 PM Steven D'Aprano 
> wrote:
> > What's the rush? Let's be objective here: what benefit are we going to
> > get from this change? Is there anyone hanging out desperately for "\d"
> > and "\-" to become SyntaxErrors, so they can... do what?
>
> So that problems can start to be detected. Time and again, Python
> users on Windows get EXTREMELY confused by the way their code worked
> perfectly with one path, then bizarrely fails with another. That is a
> very real problem, and the problem is that it appeared to work when
> actually it was wrong.
>
> Python has a history of fixing these problems. It used to be that
> b"\x61\x62\x63\x64" was equal to u"abcd", but now Python sees these as
> fundamentally different. Data-dependent bugs caused by a syntactic
> oddity are a language flaw that needs to be fixed.
>
> > Because our processes don't work the way we assumed, it turns out that
> > in practice we haven't given developers the deprecation period we
> > thought we had. Read Nathaniel's post, if you haven't already done so:
> >
> >
> https://mail.python.org/archives/list/python-dev@python.org/message/E7QCC74OBYEY3PVLNQG2ZAVRO653LD5K/
> >
> > He makes a compelling case that while we might have had the promised
> > deprecation period by the letter of the law, in practice most developers
> > will have never seen it, and we will be breaking the spirit of the
> > promise if we continue with the unmodified plan.
>
> Yes, that's a fair complaint. But merely pushing the deprecation back
> by a version is not solving it. There has to be SOMETHING done
> differently.
>
> > And yet here we are rushing through a breaking change in an accelerated
> > manner, for a change of marginal benefit.
>
> It's not a marginal benefit. For people who try to teach Python on
> multiple operating systems, this is a very very real benefit. Just
> because YOU don't see the benefit doesn't mean it isn't there.
>
> > > Otherwise, all you're doing is saying "I wish this
> > > problem would just go away".
> >
> > No, I'm saying we don't have to rush this into 3.8. Let's keep the
> > warning silent and push everything back a release.
> >
> > Now is better than never.
> > Although never is often better than *right* now.
>
> Not sure how the Zen supports what you're saying there, since you're
> specifically saying "not never, not now, just later". But what do you
> actually mean by not rushing this into 3.8?
>
> > Right now, we're looking at a seriously compromised user-experience for
> > 3.8. People are going to hate these warnings, many of them won't know
> > what to do with them and will be sure that Python is buggy, and for very
> > little benefit.
>
> Then the problem is that people blame Python for these warnings. That
> is a problem to be solved; we need people to understand that a warning
> emitted by a library is a *library bug* not a language flaw.
>
> > > Library authors can start _right now_ fixing their code so it's more
> > > 3.8 compatible.
> >
> > Provided that (1) they are aware that this is a problem that needs to be
> > fixed, and (2) they have the round tuits to actually fix it by 3.8.0.
> > Neither are guaranteed.
>
> (1) Yes it is, see above; (2) fair point, but this is restricted to
> string literals and can be detected simply by compiling the code, so
> it's a reasonably findable problem.
>
> > > ("More" because 3.8 doesn't actually break anything.)
> > > What is actually gained by waiting longer
> >
> > We gain the avoidance of a painful experience in 3.8 for a significant
> > number of users and third-party devs.
> >
> > The question we haven't had answered is what we gain by pushing through
> > with the original plan. Plenty of people have said "Let's just do it"
> > but as far as I can see not one has explained *why* we should put end-
> > users and library developers through this frustrating and annoying
> > rushed deprecation period.
>
> And unless you have a plan to do something different in 3.8 that
> ensures that library devs see the warnings, there's no justification
> for the delay. All you'll do is defer the 

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

2020-11-13 Thread Joao S. O. Bueno
On Fri, 13 Nov 2020 at 15:53, Brandt Bucher  wrote:

> Paul Sokolovsky wrote:
> > Use punctuation ("sigils") to mark as-binding terms. This choice still
> seems to be under-considered. (As in: it doesn't seem like many people,
> including the PEP authors, tried to say "indeed, what if?" and feel thru
> it. I mean, try really hard. I trust the "gang of 4" spent maybe whole few
> hours on that and delivered "no" to all us. It's still not the same as
> dozens of people trying it over a few months).
>
> To anyone actually wondering how much time and mental energy we’ve spent
> on a particular issue: please take a look at our tracker before guessing
> “maybe whole few hours”:
>
> - Issue #1(!), April, 29 comments:
> https://github.com/gvanrossum/patma/issues/1
> - Issue #90, June, 84 comments:
> https://github.com/gvanrossum/patma/issues/90
> - Issue #92, June, 33 comments:
> https://github.com/gvanrossum/patma/issues/92
> - Issue #105, June, 17 comments:
> https://github.com/gvanrossum/patma/issues/105
> - Issue #143, August, 7 comments:
> https://github.com/gvanrossum/patma/issues/143
>
> (I won't judge anyone for skimming a bit; it's a *lot* of discussion. Do
> note, though, that for months I was one of the proponents of store sigils
> like `?` until I was eventually convinced otherwise.)
>
> That's also not counting side-discussions in other issues, countless
> mailing list threads, two competing PEPs that make many of the same
> choices, a video call with the SC, etc.
>
> I'll also add, for anyone considering choosing yet another ASCII symbol
> off their keyboard and proposing it as a “novel”, “intuitive” marker: one
> problem with most of the hastily suggested adornments are that they do not
> nest very well, for even simple cases. Further, the fact that constructions
> like `p = Point(x, y)` look exactly the same as deconstructions like `case
> Point(x, y):` is absolutely intentional (which touches back on Guido’s
> “rhyme” comment last night).
>
> Very briefly, compare the current syntax:
>
> ```
> case first, *middle, last:
> rebuilt = first, *middle, last
> case {"key": value, **rest}:
> rebuilt = {"key": value, **rest}
> case Point(x=a, y=b):
> rebuilt = Point(x=a, y=b)
> ```
>
> with (using your own syntactic flavor):
>
> ```
> case >first, *>middle, >last:
> rebuilt = first, *middle, last
> case {"key": >value, **>rest}:
> rebuilt = {"key": value, **rest}
> case Point(x=>a, y=>b):
> rebuilt = Point(x=a, y=b)
> ```
>

Well, this example is a bit unfair, since you don't present a case where
there would be
matching values in variables that we would want to compare - which is the
solution
that is being brought up.

And even in that case, while I can see:

case Point(x=>a, y=>b):

and immediately read it as "attribute x from point goes into a",
the line in the current proposal doing the same:
case Point(x=a, y=b):
is far from being immediately obvious (Am I creating a new Point?
Am i assigning "a" to "x"? If so, where does "a" come from??)



> (I had to stop and think *hard* where exactly the `>` should go in
> `*middle` and `**rest`. I'm not confident I made the correct guess, either.)
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/7SJ2SOPRD6XOAISOYXONKXUKB3JMLYNU/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KTRXIM7A3OATCHZZXBULLSNZZ3BNSGJK/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

2020-11-13 Thread Joao S. O. Bueno
On Fri, 13 Nov 2020 at 17:36, Jim J. Jewett  wrote:

> I *hope* this was a typo!  If
>
> case Point(x=a, y=b):
>
> assigns to a and b (instead of x and y, as in a normal call), then that is
> ... going to be very easy for me to forget, and to miss even when I'm aware
> of it.
>

No typo -  this is _precisely_what the main proposal on PEPs 634, 635 and
636 is suggesting, and tha PEP 642 is trying to avoid.
Here it is working as is  on my Python with PEP 622 build:

```
Python 3.10.0a0 (heads/patma:1ba56a003b, Aug  6 2020, 02:00:58)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.17.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: from dataclasses import dataclass


In [2]: @dataclass
  ...: class Point:
  ...: x: float
  ...: y: float
  ...:


In [3]: def get_coords(p):
  ...: match p:
  ...: case Point(x=a, y=b):
  ...: return a, b
  ...: case _:
  ...: raise TypeError()
  ...:


In [4]: get_coords(Point(3, 4))

Out[4]: (3, 4)

```



>
> -jJ
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/F66J72JUEAUKBM5VDSMG4HRHUEQBWI5M/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ASAMVXQGHJ6JZH3NPKRYRAV7F7VCMAW6/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

2020-11-14 Thread Joao S. O. Bueno
On Sat, 14 Nov 2020 at 10:16, Nick Coghlan  wrote:

> On Fri, 13 Nov 2020 at 09:39, David Mertz  wrote:
> >
> > I have read a great deal of discussion on the pattern matching PEPs and
> less formal discussions.  It is possible I have overlooked some post in all
> of that, of course.
> >
> > ... OK, just saw Guido's "wait for new SC" comment, which I suppose
> applies to this too :-).
> >
> > One idea that I cannot recall seeing, but that seems to make sense to me
> and fit with Python's feel is using a WORD to distinguish between a
> variable value and a binding target.  That is, instead of a special symbol
> prefixing or suffixing a name, either to indicate it is or is not a binding
> target.  Of course, whether the extra word would be used for binding or for
> NOT binding is a question still.
>
> If someone was prepared to pursue this to the level of writing a 3rd
> competing PEP, the variant I would personally like to see written up
> is the one where capture patterns are all prefixed with the keyword
> `as`.
>
> PEP 634 already uses the `PATTERN as NAME` syntax to combine other
> match patterns with a capture pattern, and I'm going to be amending
> PEP 642 to propose using `as` when embedding capture patterns inside
> class patterns (`ATTR as NAME`) and mapping patterns (`KEY as NAME`).
> From there, it's an entirely plausible step to also require the `as`
> prefix on capture patterns in sequence patterns and as top level
> standalone patterns.
>
> I personally don't think that extra step would be a good idea due to
> the inconsistency with name binding and iterable unpacking in regular
> assignment statements (if I liked the idea, I'd have already included
> it in PEP 642), but I think "anchor match patterns in normal
> expressions rather than assignment target syntax" is a credible enough
> idea that the overall design process would benefit from having a
> champion write it up.
>
> > To me these read better than the punctuation characters.  But I guess
> some folks have suggested enlisting 'as', which is a word, of course.
>
> Indeed, and one that doesn't look too bad for top level patterns:
>
> NOT_FOUND = 404
> match http_code:
>   case 200:
>   print("OK document")
>   case NOT_FOUND:  # use the variable value
>   print("Document not found")
>   case as other_code:  # bind this name
>   print("Other HTTP code")
>
> It starts to look a bit more strange when matching sequences, though:
>
> match seq:
> case as first, *middle, as last:
> ... # Or should that be "*as middle"?
>

Although the spacing there should probably remain optional, I think
that "* as middle" is very straightforward and easy to read.


>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/LKRWAQX57OJANWQHG2SWL2UG4ZZRRKPF/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GFVLLQVHN2QWNX6LWHESBGRMXHLF3Z74/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: __init_subclass__ and metaclasses

2020-12-24 Thread Joao S. O. Bueno
Actually, there are a few steps that `type.__new__`  perform that are not
customizable in metaclasses.

I had sometimes thought about mailing this here, or Python ideas, but could
not
come up with a "real world" use case where the customization of those
would be meaningful.

Let'me see if I recall all cases - two of them are the calls to
`__init_subclass__` and the descriptors `__set_name__` as you put it,
I think there is a third behavior that can't be separated from
`type.__new__` - but
I can't remember it now


Anyway, the "thing to do" that always occurred to me about it is to add
"soft" method slots
to `type` itself - so that `type.__new__` would call those  on the
corresponding initialization phases.

Since these are to be run only when classes are created, their impact
should be negligible.

In other words, have `type` implement methods like `__run_init_subclass__`,
`__run_descriptor_setname__`,
(and one for the other task I can't remember now). So, all metaclass code
written up to today remains valid,
and these behaviors become properly customizable.

Adding keyword parameters to `type.__new__`, IMHO, besides a little bit
fishy as we are talking of
arguments to change the behavior of the method, would themselves compete
and have to be
filtered out, or otherwise special-cased in the `__init_subclass__` method
itself.
I mean - let's suppose we add `__suppress_init_subclass__` as an named
parameter to
`type.__new__` - what would happen with this argument in
`__init_subclass__` ? Would it show
up in the kwargs? Otherwise it would be the _only_  kwarg popped out and
not passed
to __init_subclass__, being an inconvenient exception.

Having an overridable, separate, method in type to run __init_subclass__
and __set_name__
bypass these downsides.

In time, Happy holidays everyone!

   js
 -><-

On Fri, 25 Dec 2020 at 00:38, Ethan Furman  wrote:

> PEP 487 introduced __init_subclass__ and __set_name__, and both of those
> were wins for the common cases of metaclass usage.
>
> Unfortunately, the implementation of PEP 487 with regards to
> __init_subclass__ has made the writing of correct
> metaclasses significantly harder, if not impossible.
>
> The cause is that when a metaclass calls type.__new__ to actually create
> the class, type.__new__ calls the
> __init_subclass__ methods of the new class' parents, passing it the newly
> created, but incomplete, class.  In code:
>
> ```
> class Meta(type):
>  #
>  def __new__(mcls, name, bases, namespace, **kwds):
>  # create new class, which will call __init_subclass__ and
> __set_name__
>  new_class = type.__new__(mcls, name, bases, namespace, **kwds)
>  # finish setting up class
>  new_class.some_attr = 9
> ```
>
> As you can deduce, when the parent __init_subclass__ is called with the
> new class, `some_attr` has not been added yet --
> the new class is incomplete.
>
> For Enum, this means that __init_subclass__ doesn't have access to the new
> Enum's members (they haven't beet added yet).
>
> For ABC, this means that __init_subclass__ doesn't have access to
> __abstract_methods__ (it hasn't been created yet).
>
> Because Enum is pure Python code I was able to work around it:
> - remove new __init_subclass__ (if it exists)
> - insert dummy class with a no-op __init_subclass__
> - call type.__new__
> - save any actual __init_subclass__
> - add back any new __init_subclass__
> - rewrite the new class' __bases__, removing the no-op dummy class
> - finish creating the class
> - call the parent __init_subclass__ with the now complete Enum class
>
> I have not been able to work around the problem for ABC.
>
> Two possible solutions I can think of:
>
> - pass a keyword argument to type.__new__ that suppresses the call to
> __init_subclass__; and
> - provide a way to invoke new class' parent's __init_subclass__ before
> returning it
>
> or
>
> - instead of type.__new__ doing that work, have type.__init__ do it.
>
> Thoughts?
>
> --
> ~Ethan~
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/ZMRRNSFSLJZDGGZ66CFCYQBINU62CDNX/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OCHSRMW44UUA5ESY2W54KTN64MZH2KFE/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: __init_subclass__ and metaclasses

2020-12-28 Thread Joao S. O. Bueno
For the record - the 3rd process that is currently un-customizable when
creating a class, i.e. things that happen in an opaque way inside
`type.__new__`,
is the ABC class machinery. I could not recall it when
writing the previous e-mail.

Still - I think this might be very little disruptive, and yet provide
metaclasses back with full customization power, including
being able to address the problem brought up by Etham.


   js
 -><-

On Fri, 25 Dec 2020 at 01:40, Joao S. O. Bueno 
wrote:

> Actually, there are a few steps that `type.__new__`  perform that are not
> customizable in metaclasses.
>
> I had sometimes thought about mailing this here, or Python ideas, but
> could not
> come up with a "real world" use case where the customization of those
> would be meaningful.
>
> Let'me see if I recall all cases - two of them are the calls to
> `__init_subclass__` and the descriptors `__set_name__` as you put it,
> I think there is a third behavior that can't be separated from
> `type.__new__` - but
> I can't remember it now
>
>
> Anyway, the "thing to do" that always occurred to me about it is to add
> "soft" method slots
> to `type` itself - so that `type.__new__` would call those  on the
> corresponding initialization phases.
>
> Since these are to be run only when classes are created, their impact
> should be negligible.
>
> In other words, have `type` implement methods like
> `__run_init_subclass__`, `__run_descriptor_setname__`,
> (and one for the other task I can't remember now). So, all metaclass code
> written up to today remains valid,
> and these behaviors become properly customizable.
>
> Adding keyword parameters to `type.__new__`, IMHO, besides a little bit
> fishy as we are talking of
> arguments to change the behavior of the method, would themselves compete
> and have to be
> filtered out, or otherwise special-cased in the `__init_subclass__` method
> itself.
> I mean - let's suppose we add `__suppress_init_subclass__` as an named
> parameter to
> `type.__new__` - what would happen with this argument in
> `__init_subclass__` ? Would it show
> up in the kwargs? Otherwise it would be the _only_  kwarg popped out and
> not passed
> to __init_subclass__, being an inconvenient exception.
>
> Having an overridable, separate, method in type to run __init_subclass__
> and __set_name__
> bypass these downsides.
>
> In time, Happy holidays everyone!
>
>js
>  -><-
>
> On Fri, 25 Dec 2020 at 00:38, Ethan Furman  wrote:
>
>> PEP 487 introduced __init_subclass__ and __set_name__, and both of those
>> were wins for the common cases of metaclass usage.
>>
>> Unfortunately, the implementation of PEP 487 with regards to
>> __init_subclass__ has made the writing of correct
>> metaclasses significantly harder, if not impossible.
>>
>> The cause is that when a metaclass calls type.__new__ to actually create
>> the class, type.__new__ calls the
>> __init_subclass__ methods of the new class' parents, passing it the newly
>> created, but incomplete, class.  In code:
>>
>> ```
>> class Meta(type):
>>  #
>>  def __new__(mcls, name, bases, namespace, **kwds):
>>  # create new class, which will call __init_subclass__ and
>> __set_name__
>>  new_class = type.__new__(mcls, name, bases, namespace, **kwds)
>>  # finish setting up class
>>  new_class.some_attr = 9
>> ```
>>
>> As you can deduce, when the parent __init_subclass__ is called with the
>> new class, `some_attr` has not been added yet --
>> the new class is incomplete.
>>
>> For Enum, this means that __init_subclass__ doesn't have access to the
>> new Enum's members (they haven't beet added yet).
>>
>> For ABC, this means that __init_subclass__ doesn't have access to
>> __abstract_methods__ (it hasn't been created yet).
>>
>> Because Enum is pure Python code I was able to work around it:
>> - remove new __init_subclass__ (if it exists)
>> - insert dummy class with a no-op __init_subclass__
>> - call type.__new__
>> - save any actual __init_subclass__
>> - add back any new __init_subclass__
>> - rewrite the new class' __bases__, removing the no-op dummy class
>> - finish creating the class
>> - call the parent __init_subclass__ with the now complete Enum class
>>
>> I have not been able to work around the problem for ABC.
>>
>> Two possible solutions I can think of:
>>
>> - pass a keyword argument to type.__new__ that suppresses the call to
>> __init_subclass__; and
>> 

[Python-Dev] Re: Descriptors in dataclasses fields

2021-01-04 Thread Joao S. O. Bueno
I think you are complicating things just because there is no easy way to
tell mypy
that although you are assigning a descriptor to a class variable
in the class body, it will be used as a normal instance attribute
afterwards - and
it is the type used in the instance attribute that mypy should care for,

And then
maybe, the specs of static type checking could get a feature to allow
assigning one thing at class declaration and another thing at instance
working
(otherwise, not only dataclasses, but anything using custom descriptors
would not work with static type checking).

As a workaround, you could just "cast" our descriptor instance to the
type the attribute will actually hold - mypy should not complain:
```
@dataclass
class Item:
price: Decimal = typing.cast(Decimal, MyDescriptor())

```

On Sun, 3 Jan 2021 at 22:48, Josue Balandrano Coronel 
wrote:

> I've been exploring dataclasses for a few months now and they've proven to
> be very useful.
>
> The only downside is that there's not a simple way to use descriptors.
>
> Descriptors only work on class attributes (as per the docs:
> https://docs.python.org/3/howto/descriptor.html#closing-thoughts). This
> means that to use a descriptor in a data class we have to use
> typing.ClassVar like this
>
> @dataclass
> class Item:
> name: str
> price: typing.ClassVar[Decimal] = PriceValidator()
>
> Which is totally fine because of how descriptors work the previous syntax
> is a feature in dataclasses, IMHO.
>
> But, there's not a straight forward way to pass a value to the descriptor
> on init. Because ClassVars are not used by @dataclass to do its thing (as
> per the docs:
> https://docs.python.org/3/library/dataclasses.html#class-variables)
>
> This means that in the example above `price` is not going to be a
> parameter of the class Item's __init__ method. So the only way to do this
> is to either create an InitVar field or a regular field and then pass the
> value to the descriptor in __post_init__
>
> @dataclass
> class Item:
> name: str
> price_val: InitVar[Decimal]
> price: typing.ClassVar[Decimal] = PriceValidator()
>
> def __post_init__(self, price_val: Decimal) -> None:
> self.price = price_val
>
> When using a regular field we can double the field's purpose by making it
> the field the descriptor is going to use:
>
> @dataclass
> class Item:
> name: str
> _price: Decimal
> price: typing.ClassVar[Decimal] = PriceValidator()
>
> def __post_init__(self) -> None:
> self.price = self._price
>
> And then in the descriptor implement __set_name__ like so:
>
> def __set_name(self, owner, name):
> self.name = f"_{name}"
>
>
> Personally, I don't like either option because it adds noice to the data
> class definition. Using an InitVar is the better option because that
> variable is clearly defined as init only and it's not present in an
> instance. Using a regular field adds unnecessary noice to the data class.
>
> Also, I think it clashes with the intent of descriptors since they're
> supposed to manage their data in any way they want.
>
> My questions are:
>
> - Are my assumptions correct?
> - Is this the intended behavior? Or what's the preferred way of using a
> descriptor in a dataclass field?
> - If this is not intended, could it be possible to add a `descriptor`
> parameter to the `field` method and treat the field accordingly?
>
> I couldn't find any information on the docs or the PEP. I could"ve missed
> something, sorry if this is the case :)
>
> Thanks!
>
> --
> Josue
> https://www.rmcomplexity.com
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/UOMBDIVNRG3DS6UHWSOF4JTLIPXEENCT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HRIDJO4VX4F4MNOHODMZJNAOV7NP2VL7/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

2021-03-03 Thread Joao S. O. Bueno
Just to add +1 for Paul's concerns.

Even though ExceptionGroups "are not supposed" to not
leak into caller code, don't mean they "won't". Making  "except Exception"
catch them would make this part a non issue, and the
feature looks great otherwise.

On Wed, 3 Mar 2021 at 13:44, Paul Moore  wrote:

> On Wed, 3 Mar 2021 at 14:59, Irit Katriel 
> wrote:
> >> 2. Given the above, why even have a means of grouping BaseExceptions
> >> at all? Why not just have ExceptionGroup that can only catch instances
> >> of Exception?
> >
> > Because the IGotInterrupted alternative involves wrapping a
> BaseException by an Exception, which is not something we should push people
> into doing (it's not that different from allowing ExceptionGroup to wrap
> BaseExceptions directly).
>
> That's a fair point.
>
> > What's the harm/complication in offering a
> BaseExceptionGroup(BaseException) in addition to
> ExceptionGroup(BaseExceptionGroup, Exception)?
>
> Similar to the argument for "except Exception". Applications that trap
> KeyboardInterrupt so that they can exit cleanly without an ugly
> traceback will no longer trap *all* keyboard interrupts, as they could
> miss grouped ones.
>
> If we accept that grouped exceptions should never escape out of a
> well-defined context, then this wouldn't be such an issue. But there's
> nothing in the PEP that enforces that, and there *is* code that needs
> to be prepared for "any sort of result". It's the except Exception
> argument again.
>
> So code that wants to exit cleanly in the face of Ctrl-C will need to
> be rewritten from:
>
> try:
> main()
> except KeyboardInterrupt:
> print("User interrupted the program. Exiting")
> sys.exit(1)
>
> to:
>
> try:
> try:
> main()
> except KeyboardInterrupt:
> print("User interrupted the program. Exiting")
> sys.exit(1)
> except *KeyboardInterrupt:
> print("User interrupted the program. Exiting")
> sys.exit(1)
>
> Did I miss an easier way of writing this code? And worse, how would I
> write it so that it was portable between Python 3.9 and later versions
> (which is a common requirement for library code - admittedly library
> code wouldn't normally be doing this sort of top-level trap, but it
> could just as easily be "catch Ctrl-C and do a bit of tidy-up and
> re-raise").
>
> > I think the only reason you're comfortable with having to select between
> the exceptions that were raised and discard some of them is because that's
> where we are today. The PEP lists several standard library and other APIs
> that discard errors because they need to pick one. That's what we're trying
> to fix.
>
> Maybe. But I'm not looking at it as being "comfortable" with the
> current situation, but rather as "I don't use any of these new
> features, why am I having to change my code to accommodate stuff I
> don't use?" If I own the full stack, that's not an issue, but
> frameworks and libraries typically have to interact with other users'
> code, and there the contract has changed from "do what you like in
> your code and I'll cope" to "do what you like in your code as long as
> you don't let an exception group escape, and I'll cope"... And I have
> to change *my* code to get the old contract back.
>
> But it's a small point in the wider scheme of things, and I'm not
> going to labour the point any more. Thanks for listening and taking
> the time to reply.
>
> Paul
>
> Paul
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/WSUEOGDCBBOZ7PCQGUCXKIZEZ7RK34LK/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CYV3RDTUZM2LBF6NLCHA6PTJMWG4CKF6/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Suggestion About Python Syntax

2021-03-03 Thread Joao S. O. Bueno
That is covered.
Try typing "from __future__ import braces".

On Wed, 3 Mar 2021 at 14:47, Anthony Farino 
wrote:

> I love the Python scripting language, but there’s something that would
> make it much better. Almost every other programming language uses curly
> braces to enclose blocks of code and semicolons after the lines of code.
> That means that:
>
>1.
>
>You can have as much white space as you want.
>2.
>
>You don’t need to worry about indentation, and you can indent whenever
>you want.
>
> I hope that you consider these issues and fix them in Python 4 (if you
> ever make it).
>
> Sincerely, Anthony, age 10.
>
>
> --
>mmm#
>##   m mm   mm#mm  # mmmmm   m mm   m   m
>   #  #  #"  ###"  #  #" "#  #"  #  "m m"
>   #mm#  #   ###   #  #   #  #   #   #m#
>  ## #   #"mm  #   #  "#m#"  #   #   "#
> m"
>""
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/RZR2O3Y6Z6RCAXW72Y4WPWZ6HN3MYVFJ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/MLNWBYE3GJ4ZUXLPQGEP4UIANP72NTSX/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: aiter/anext review request

2021-03-19 Thread Joao S. O. Bueno
On Fri, 19 Mar 2021 at 14:38, Paul Bryan  wrote:

> On Fri, 2021-03-19 at 10:22 -0700, Guido van Rossum wrote:
>
> I’m not convinced that we need aiter(x, sentinel) at all — for iter() it’s
> mostly a legacy compatibility API.
>
>
> I'm feel like I'm going to learn something today. To date, the pattern
> I've used for getting the first item from an iterable:
>
> next(iter(i))
>
>
> What's the recommended alternative?
>

I end up doing this most times:

def first(i):
return next(iter(i))

Seens too simple to request to be in the sdlib, and it is so simple that
would be forgotten if it were
in any 3rd party extension


>
> Paul
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/2XNN6NYR6WXKVQN5UDCPVMY7KRDKF3BG/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PVR3LAKIXS24MC5FAUYNERIBDFI6KJKQ/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: The repr of a sentinel

2021-05-14 Thread Joao S. O. Bueno
Since the subject is this,
I will note that past week, I resorted twice to create an Enum with a
single element,
and then alias the element on the module namespace, so that it would work
as a "polished" sentinel.

So:

import enum

class Whatever(enum.Enum):
 EMPTY = "EMPTY"

EMPTY = Whatever.EMPTY

A "repeat yourself three times" - certainly not that nice.
But its use was a bit off the ones listed here in a sense these
are meant to be explicitly passed to some methods (rather,
placed inside data structures) to indicate a desired behavior.



On Fri, 14 May 2021 at 21:03, Nick Coghlan  wrote:

> On Sat, 15 May 2021, 5:39 am Tal Einat,  wrote:
>
> (snip useful feature summary)
>
> The common `SENTINEL = object()` idiom fails #3, #4 and #5. This is
>> what I've been using for years, and I now think that it isn't good
>> enough. This not having a nice repr is what started this thread.
>>
>> I'd also personally prefer something simple, ideally without a new
>> class or module.
>>
>
> The key advantage of a new base class is that it offers a way to
> communicate a shift in the recommended development idiom. "sentinel =
> object()" is entrenched enough that I would expect that only a
> "types.Sentinel" base class would stand a good chance of displacing it.
>
> Why the "types" module? I don't think this is important enough to be a
> builtin type, and the types module is cheap to import, doesn't bring in
> many transitive dependencies, and the purpose of the new base class would
> be defining custom sentinel types with various desirable properties.
>
> Cheers,
> Nick.
>
>>
>
>
>> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/V67I4A6WX6INEAGGSJWYFX4WKQHA73NW/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/2CKU2DRT3T7W7FX6PJARC7FUGB3Q7WKV/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: name for new Enum decorator

2021-05-28 Thread Joao S. O. Bueno
I think a longer-named decorator, with a name that actually
describes its behavior would be better than any smart short name
in this case.

"check_all_bits_defined" or something along it.

On Fri, 28 May 2021 at 18:30, Ethan Furman  wrote:

> On 5/28/21 12:43 AM, Petr Viktorin wrote:
>  > On 28. 05. 21 5:24, Ethan Furman wrote:
>
>  >>  class FlagWithMasks(IntFlag):
>  >>  DEFAULT = 0x0
>  >>
>  >>  FIRST_MASK = 0xF
>  >>  FIRST_ROUND = 0x0
>  >>  FIRST_CEIL = 0x1
>  >>  FIRST_TRUNC = 0x2
>  >>
>  >>  SECOND_MASK = 0xF0
>  >>  SECOND_RECALC = 0x00
>  >>  SECOND_NO_RECALC = 0x10
>  >>
>  >>  THIRD_MASK = 0xF00
>  >>  THIRD_DISCARD = 0x000
>  >>  THIRD_KEEP = 0x100
>  >>
>  >> Here we have three flags (FIRST_MASK, SECOND_MASK, THIRD_MASK) that
> are aliasing values
>  >> that don't exist, but it seems intentional and not an error.
>  >
>  > Are you looking for a decorator for the whole Enum, or a way to mark
> individual *values* as masks?
>
> The decorator is for whole enum.  The issue is not that some values are
> masks, but whether the absence of named bits
> covered by the mask is an error.
>
> --
> ~Ethan~
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/OM5M774MP5QPLFXZ7OVGBPR7ZFB6X35A/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WX7YCSRRDJWLVJUMLGBZL34OP7JW4MDQ/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 558: Defined semantics for locals()

2021-07-21 Thread Joao S. O. Bueno
Hi Nick - as for:
> Keys that are not defined as local or closure variables on the underlying
frame are still written to the f_locals cache on optimised frames.

This means current behavior will be kept, right? the f_locals cache is
persistent across descending calls
from the current frame?

To be more specific - I have a somewhat toy package (though I've used it on
serious code on occasion prior
to having the "walrus" operator) which allows one to keep an anonymous
stack on the current running frame
and operate on it with "push", "pop", "dup", etc... calls. The stack is a
list referenced in a "hidden" variable
created on the first call to "push".
>From my reading that would still work, right?


On Sun, 18 Jul 2021 at 03:01, Nick Coghlan  wrote:

> Hi folks,
>
> It's been a long time coming, but I've finally made enough progress on
> the reference implementation that I think it's time to ask Nathaniel
> to pronounce on the current iteration of PEP 558 (Defined semantics
> for locals()).
>
> The rendered version is up at
> https://www.python.org/dev/peps/pep-0558/, and I've included the plain
> text version below.
>
> For those that are reading the PEP for the first time, the gist is:
>
> * standardise on Python 3.10 behaviour *except* that locals() at
> function scope returns a fresh snapshot every time instead of a
> reference to the frame level state cache
> * make the Python level frame.f_locals on optimised frames a
> write-through proxy that keeps both the real fast locals storage and
> the C level f_locals state cache up to date
> * add new C APIs that allow C code to explicitly request the semantics
> the client code actually wants ("behave like the Python locals()
> builtin", "always make a copy", "always provide a read-only view")
> * soft-deprecate the legacy PyEval_GetLocals() API (while ensuring it
> still works)
> * use the new features to significantly improve the performance of
> code execution tracing hooks implemented in Python
>
> For those that remember reading older versions of the PEP, the key
> changes relative to the last discourse thread (back in late 2019/early
> 2020) are:[...]
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/LF7FOZFS6FI2757HPDDHV5DYBG4G3SWT/
Code of Conduct: http://python.org/psf/codeofconduct/


Re: [Python-Dev] cffi in stdlib

2013-02-27 Thread Joao S. O. Bueno
On 27 February 2013 10:31, Antoine Pitrou  wrote:

> Le Wed, 27 Feb 2013 12:15:05 +1300,
> Greg Ewing  a écrit :
> > Antoine Pitrou wrote:
> > > Or we'll go straight to 5.
> > > (or switch to date-based numbering :-))
> >
> > We could go the Apple route and start naming them after
> > species of snake.
>
> We have to find sufficiently silly species of snakes, though.
>

Monty Python feature movies.
There are less than snake species, but imagine porting
Django to be able to run on Life of Brian!

>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] can't assign to function call

2013-03-18 Thread Joao S. O. Bueno
On 18 March 2013 10:50, Neal Becker  wrote:
> def F(x):
> return x
>
> x = 2
> F(x) = 3
>
> F(x) = 3
> SyntaxError: can't assign to function call
>
> Do we really need this restriction?  There do exist other languages without 
> it.

What?
I mean...what are you even talking about?
Assignments are to "names" - names are not Python objects and it is
not something that can be returned from a function call.

If you are meaning mathematical equation like functionality, I
recommend you to try "SymPy" - the Library for symbolic mathematics.

I can't make sense of what you want to perform by "assigning to a
function call", and given the time without a reply to this e-mail, I
think I am not the only one there.


  js
 -><-





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


Re: [Python-Dev] IDLE in the stdlib

2013-03-21 Thread Joao S. O. Bueno
On 20 March 2013 23:53, Steven D'Aprano  wrote:
> I also note that in the last few weeks, I've seen at least two instances
> that I recall of a beginner on the tu...@python.org mailing list being
> utterly confused by Python's Unicode handling because the Windows command
> prompt is unable to print Unicode strings.

It can be worst than that - in i18nes Windows installs, the DOS Prompt sometimes
have a different encoding than the Windows running -  for example, for
pt_BR Windows, all UI apps run using latin1, but the CP uses a CP850 encoding
which generates _different_ characters for the same codes.

As someone who form times to times lecture a introductory workshop of
Python to people running Windows, I second Terry's long message - and
I highlight
Raymond's """ Without IDLE, a shocking number of people would
create Python files using notepad. """


   js
  -><-
>
>
> Thanks Terry.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Sharing docstrings between the Python and C implementations of a module

2013-04-15 Thread Joao S. O. Bueno
On 15 April 2013 13:31, Eli Bendersky  wrote:
>
>
>
> On Mon, Apr 15, 2013 at 3:45 AM, Nick Coghlan  wrote:
>>
>> On Mon, Apr 15, 2013 at 8:17 PM, Maciej Fijalkowski 
>> wrote:
>> > On Mon, Apr 15, 2013 at 9:56 AM, David Lam 
>> > wrote:
>> >> I tried to find an example in the source which addressed this, but
>> >> found that the docstrings in similar cases to be largely duplicated.
>> >> For instance, _datetimemodule.c, decimal_.c and _json.c all seem to
>> >> exhibit this docstring copy and pastage.
>> >>
>> >
>> > Hi
>> >
>> > NumPy uses a hack to deal with this problem. It has a small C function
>> > that would mutate the docstring under your feet. Personally I would
>> > prefer some sort of tagging in C source that can copy-paste stuff
>> > instead, honestly. It does sound like a good idea to share docstrings.
>> > Seems also relatively trivial to write a test that checks that they
>> > stay the same.
>>
>> It's actually even worse than that - if a subclass overrides a method,
>> it has to completely duplicate the docstring, even if the original
>> docstring was still valid. So, for example, ABCs can't provide
>> docstrings for abstract methods.
>>
>> So yeah, we end up not only duplicating between the C and Python
>> versions, but sometimes we end up duplicating between different
>> subclasses as well (datetime.datetime, datetime.date and datetime.time
>> are the worst offenders here).
>>
>> I like the idea of at least adding a test that checks the Python
>> docstring and the C docstring are the same in the duplicated cases -
>> that should be a lot easier than adjusting the build process to let
>> the C version use the Python docstrings or vice-versa (even the
>> argument clinic DSL in PEP 434 doesn't try to achieve that - it just
>> tries to cut down on the duplication within the C code itself).
>
>
> Would it make sense to think about adding this in the scope of the argument
> clinic work, or is it too unrelated? This seems like a commonly needed thing
> for large parts of the stdlib (where the C accelerator overrides Python
> code).

+1

It is a problem I was met with when building extensions  as well -
when one would like to
keep the C parts to a minimum and dynamically populate de doc-strings
from another
source with a Python script, for example.

>
> Eli
>
>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] weak refs in descriptors (http://bugs.python.org/issue17950)

2013-05-13 Thread Joao S. O. Bueno
On 13 May 2013 10:20, Maciej Fijalkowski  wrote:
> On Mon, May 13, 2013 at 1:49 PM, Kristján Valur Jónsson
>  wrote:
>> Hello python-dev.
>>
>> I‘m working on a patch to remove reference cycles from heap-allocated
>> classes:  http://bugs.python.org/issue17950
>>
>> Part of the patch involves making sure that descriptors in the class
>> dictionary don’t contain strong references to the class itself.
>>
>> This is item 2) in the defect description.
>>
>> I have implemented this via weak references and hit no issues at all when
>> running the test suite.
>>
>> But I’d like to ask the oracle if there is anything I may be overlooking
>> with this approach?  Any hidden problems we might encounter?
>>
>>
>>
>> K
>
> Hi Kristjan
>
> The strong reference there is a feature. Descriptors keep the class
> alive if somehow the class disappears and the descriptor itself does
> not. Please don't change language semantics (yes, this is a change in
> semantics), just because the test suite passes - I can assure you
> there are people doing convoluted stuff that expect this to work.
>
+1 for it being an expected behavior.

So I think it would be a nice thing to write a test that breaks under
this condition

  js
 -><-


> Cheers,
> fijal
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Ordering keyword dicts

2013-05-19 Thread Joao S. O. Bueno
On 19 May 2013 11:57, Guido van Rossum  wrote:
> Hm. Wouldn'tvevery call site be slowed down by checking for that flag?

Actually, when I was thinking on the subject I came to the same idea, of having
some functions marked differently so they would use a different call mechanism -
but them I wondered around having a different opcode for the ordered-dict calls.

Would that be feasible?

  js
 -><-



> —
> Sent from Mailbox
>
>
> On Sun, May 19, 2013 at 7:42 AM, Nick Coghlan  wrote:
>>
>> On Sun, May 19, 2013 at 11:01 PM, Antoine Pitrou 
>> wrote:
>> > The main use case seems to be the OrderedDict constructor itself.
>> > Otherwise, I can't think of any situation where I would've wanted it.
>>
>> I've had a couple related to populating other mappings where order
>> matters, at least from a predictability and readability perspective,
>> even if it's not strictly required from a standards compliance point
>> of view (think writing XML attributes, etc).
>>
>> I quite liked the idea of a simple flag attribute on function objects
>> that the interpreter checked, with a decorator in functools (or even
>> the builtins) to set it. It's not a particularly elegant solution, but
>> it would get the job done with minimal performance impact on existing
>> functions.
>>
>> Cheers,
>> Nick.
>>
>> --
>> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Add a "transformdict" to collections

2013-09-10 Thread Joao S. O. Bueno
On 10 September 2013 16:08, Paul Moore  wrote:
> If you provide "retain the last", I can't see any obvious way of
> implementing "retain the first" in application code without in effect
> reimplementing the class.

Which reminds one - this class should obviously have a method for
retrivieng the original key value, given a matching key -

d.canonical('foo') -> 'Foo'
___
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] Add a "transformdict" to collections

2013-09-10 Thread Joao S. O. Bueno
On 10 September 2013 18:06, Antoine Pitrou  wrote:
> On Tue, 10 Sep 2013 17:38:26 -0300
> "Joao S. O. Bueno"  wrote:
>> On 10 September 2013 16:08, Paul Moore  wrote:
>> > If you provide "retain the last", I can't see any obvious way of
>> > implementing "retain the first" in application code without in effect
>> > reimplementing the class.
>>
>> Which reminds one - this class should obviously have a method for
>> retrivieng the original key value, given a matching key -
>>
>> d.canonical('foo') -> 'Foo'
>
> I don't know. Is there any use case?
> (sure, it is trivially implemented)


Well, I'd expect it to simply be there. I had not thought of
other usecases for the transformdict itself -

but if I would use it and would need the original key
without such a method it would not be trivial to get it.

For example, in latim languages it is common to want
accented letters to match their unaccented counterparts
- pick my own first name "João" - if I'd use a transform to strip
the diactriticals, and have an user input "joao" - it would match,
as intended - but I would not be able to retrieve the accented version
without re-implementing the class behavior.

  js
 -><-



>
> Regards
>
> Antoine.
> ___
> 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/jsbueno%40python.org.br
___
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] Add a "transformdict" to collections

2013-09-10 Thread Joao S. O. Bueno
On 10 September 2013 18:46, Antoine Pitrou  wrote:
> On Tue, 10 Sep 2013 18:44:20 -0300
> "Joao S. O. Bueno"  wrote:
>> On 10 September 2013 18:06, Antoine Pitrou  wrote:
>> > On Tue, 10 Sep 2013 17:38:26 -0300
>> > "Joao S. O. Bueno"  wrote:
>> >> On 10 September 2013 16:08, Paul Moore  wrote:
>> >> > If you provide "retain the last", I can't see any obvious way of
>> >> > implementing "retain the first" in application code without in effect
>> >> > reimplementing the class.
>> >>
>> >> Which reminds one - this class should obviously have a method for
>> >> retrivieng the original key value, given a matching key -
>> >>
>> >> d.canonical('foo') -> 'Foo'
>> >
>> > I don't know. Is there any use case?
>> > (sure, it is trivially implemented)
>>
>>
>> Well, I'd expect it to simply be there. I had not thought of
>> other usecases for the transformdict itself -
>
> Well, it is not here for dict, set, etc.

For the simple motive that once you retrieve or find that an
element is contained in one of these classes, you already
have the canonical key. :-)

>
>> For example, in latim languages it is common to want
>> accented letters to match their unaccented counterparts
>> - pick my own first name "João" - if I'd use a transform to strip
>> the diactriticals, and have an user input "joao" - it would match,
>> as intended - but I would not be able to retrieve the accented version
>> without re-implementing the class behavior.
>
> Interesting example, thanks.
>
> Regards
>
> Antoine.
> ___
> 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/jsbueno%40python.org.br
___
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 455: TransformDict

2013-09-13 Thread Joao S. O. Bueno
I see the PEP does not contemplate a way to retrieve the original key
- like we've talked about somewhere along the thread.

On 13 September 2013 16:37, Antoine Pitrou  wrote:
> On Fri, 13 Sep 2013 22:31:02 +0300
> Serhiy Storchaka  wrote:
>> 13.09.13 21:40, Antoine Pitrou написав(ла):
>> > Both are instances of a more general pattern, where a given
>> > transformation function is applied to keys when looking them up: that
>> > function being ``str.lower`` in the former example and the built-in
>> > ``id`` function in the latter.
>>
>> Please use str.casefold in examples.
>>
>> > >>> d = TransformDict(str.lower, [('Foo': 1)], Bar=2)
>>
>> {'Foo': 1} or [('Foo', 1)].
>
> Ok, thanks.
>
>> > Providing a specialized container, not generic
>> > --
>> >
>> > It was asked why we would provide the generic TransformDict construct
>> > rather than a specialized case-insensitive dict variant.  The answer
>> > is that it's nearly as cheap (code-wise and performance-wise) to provide
>> > the generic construct, and it can fill more use cases.
>>
>> Except lightweight IdentityDict which can be implemented more efficient
>> than TransformDict(id). It doesn't need in calling the transform
>> function, computing the hash of transformed key, comparing keys.
>> But
>> perhaps in many cases TransformDict(id) is enough.
>
> That's true. But it's only important if TransformDict is the
> bottleneck. I doubt the memoizing dictionary is a bottleneck in
> e.g. the pure Python implementation of pickle or json.
>
>> > Python's own pickle module uses identity lookups for object
>> > memoization:
>> > http://hg.python.org/cpython/file/0e70bf1f32a3/Lib/pickle.py#l234
>>
>> Also copy, json, cProfile, doctest and _threading_local.
>
> Thanks, will add them.
>
> Regards
>
> Antoine.
>
>
> ___
> 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/jsbueno%40python.org.br
___
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 455: TransformDict

2013-09-13 Thread Joao S. O. Bueno
On 13 September 2013 22:40, Ethan Furman  wrote:
> On 09/13/2013 06:25 PM, MRAB wrote:
>>
>> On 14/09/2013 01:49, Steven D'Aprano wrote:
>>>
>>>
>>> Is it more common to want both the canonical key and value at the same
>>> time, or to just want the canonical key? My gut feeling is that I'm
>>> likely to have code like this:
>>>
>>>
>>> d = TransformDict(...)
>>> for key in data:
>>>  key = d.get_canonical(key)
>>>  value = d[key]
>>>  print("{}: {}".format(key, value))
>>>
>> I think I must be missing something. I thought that iterating over the
>>
>> dict would yield the original keys, so if you wanted the original key
>> and value you would write:
>>
>> for key, value in data.items():
>>  print("{}: {}".format(key, value))
>
>
> Well, that's certainly how I would do it.  ;)

I hope you are aware that this pattern does not help when one  wants
 _one_ canonical key having a non-canonical one, besides having to linearly
walk through all keys and check the "__transform__"
to each one.

I mean - given no function to retrieve the canonical key,
one would have to resort to:

my_key = data.__transform__(given_key)
for key, value in data.items():
if data.__transform__(key) == my_key:



WHich would defeat not only the purpose of a Transform dict, but the purpose
of a dict alltogether.

(of course, the one obvious way to do it would be to have the original key
stored along the value - which is just a bit less silly than the example above)


OTOH, having a `get_canonical_key` method or similar seens trivial enough-
if the only provided method retrieves the value as well, it would not
be that bad.




>
>
>
>> and if you wanted the transformed key you would apply the transform
>> function to the key.
>
>
> Indeed.  The question is:  how?  It is entirely possible that your function
> has a TransformDict alone, and no memory of the transform function used to
> create the dict...
>
> If the key transform function were saved directly on the TransformDict
> instance as, say, .transform_key, then problem solved.
>



> --
> ~Ethan~
>
> ___
> 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/jsbueno%40python.org.br
___
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 457: Syntax For Positional-Only Parameters

2013-10-08 Thread Joao S. O. Bueno
I am -1 for the optional parameters and grouping stuff -
no need to make complicated stuff easier to do  just because "range" semantics
is strange to start with.
(And one can implement a range-like funciton explictly parsing
the parameters if needed be.)

As for the "/" delimiting positional only parameters - I think it would
be nice to have. -but just that - mandatory positional only parameters.

Apart from that, I could not figure if the PEP covers a situation where the name
of a positional-only parameter is passed in as a kwarg -

def a([b],/,**kw):
   print (b)

does calling "a(b=5)" should raise a TypeError, or put "5" in
"""kw["b"]""" and leave
"b" as "undefined" ?

   js
 -><-



On 8 October 2013 22:31, Benjamin Peterson  wrote:
> 2013/10/8 Larry Hastings :
>> This PEP proposes a backwards-compatible syntax that should
>> permit implementing any builtin in pure Python code.
>
> This is rather too strong. You can certainly implement them; you just
> have to implement the argument parsing yourself. Python's
> call/signature syntax is already extremely expressive, and resolving
> call arguments to formal parameters is already a complicated (and
> slow) process. Implementing functions with such strange argument
> semantics is hardly common enough to justify the whole grouping syntax
> proposed in this PEP. -1 to that. I think I can live with "/", but
> YANGTNI still.
>
>
>
> --
> Regards,
> Benjamin
> ___
> 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/jsbueno%40python.org.br
___
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] Why does base64 return bytes?

2016-06-14 Thread Joao S. O. Bueno
On 14 June 2016 at 12:19, Steven D'Aprano  wrote:
> Is there
> a good reason for returning bytes?

What about: it returns 0-255 numeric values for each position in  a stream, with
no clue whatsoever to how those values map to text characters beyond
the 32-128 range?

Maybe base64.decode could take a "encoding" optional parameter - or
there could  be
a separate 'decote_to_text" method that would explicitly take a text codec name.
Otherwise, no, you simply can't take a bunch of bytes and say they
represent text.

João

(see ^- the "ã" ?)
___
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] Why does base64 return bytes?

2016-06-14 Thread Joao S. O. Bueno
On 14 June 2016 at 13:32, Toshio Kuratomi  wrote:
>
> On Jun 14, 2016 8:32 AM, "Joao S. O. Bueno"  wrote:
>>
>> On 14 June 2016 at 12:19, Steven D'Aprano  wrote:
>> > Is there
>> > a good reason for returning bytes?
>>
>> What about: it returns 0-255 numeric values for each position in  a
>> stream, with
>> no clue whatsoever to how those values map to text characters beyond
>> the 32-128 range?
>>
>> Maybe base64.decode could take a "encoding" optional parameter - or
>> there could  be
>> a separate 'decote_to_text" method that would explicitly take a text codec
>> name.
>> Otherwise, no, you simply can't take a bunch of bytes and say they
>> represent text.
>>
> Although it's not explicit, the question seems to be about the output of
> encoding (and for symmetry, the input of decoding).  In both of those cases,
> valid output will consist only of ascii characters.
>
> The input to encoding would have to remain bytes (that's the main purpose of
> base64... to turn bytes into an ascii string).
>

Sorry, it is 2016, and I don't think at this point anyone can consider
an ASCII string
as a representative pattern of textual data in any field of application.
Bytes are not text. Bytes with an associated, meaningful, encoding are text.
  I thought this had been through when Python 3 was out.

Unless you are working with COBOL generated data (and intending to keep
the file format) , it does not make sense in any real-world field.
(supposing your
Cobol data is ASCII and nort EBCDIC).


> -Toshio
___
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] Why does base64 return bytes?

2016-06-14 Thread Joao S. O. Bueno
On 14 June 2016 at 14:45, Random832  wrote:
> On Tue, Jun 14, 2016, at 13:05, Joao S. O. Bueno wrote:
>> Sorry, it is 2016, and I don't think at this point anyone can consider
>> an ASCII string
>> as a representative pattern of textual data in any field of application.
>> Bytes are not text. Bytes with an associated, meaningful, encoding are
>> text.
>>   I thought this had been through when Python 3 was out.
>
> Of all the things that anyone has said in this thread, this makes the
> *least* contextual sense. The input to base64 encoding, which is what is
> under discussion, is not text in any way. It is images, it is zip files,
> it is executables, it could be the output of os.urandom (at least,
> provided it doesn't block ;) for all anyone cares.
>
> The *output* is only an ascii string in the sense that it is a text
> string consisting of characters within (a carefully chosen subset of)
> ASCII's repertoire, but the output wasn't what he was claiming should be
> bytes in the sentence you replied to. Is your objection to the phrase
> "ascii string"?
Sorry - everything I wrote, I was thinking about _decoding_ base 64.
As for the result of an encoded base64, yes, of course it fits into ASCII.

The arguments about compactness and what is most likely to happen
next applies (transmission trhough a binary network protocol),
 but the strong objection I had was just because I thought it was
a suggestion of decoding base 64 automatically to text without providing
a text encoding.

> ___
> 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/jsbueno%40python.org.br
___
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] PEP487: Simpler customization of class creation

2016-07-27 Thread Joao S. O. Bueno
Hi -  sorry for steppign in late - I've just reread the PEP and tried
out the reference implementation, and I have two sugestions/issues
with it as is:

1)
Why does `__init_subclass__` is not run in the class it is defined itself??
That makes no sense to me as in very unpythonic.

I applied the patch at issue, 27366 went to the terminal, and created
a "hello world"
__init_subclass__ with a simple print statement, and was greatly
surprised that it did not printout. Only upon reviewing the PEP text I
inferred that it was supposed to work (as it did) in further
subclasses of my initial class.


After all, issubclass(A, A) is usually True.

I pledge for this behavior to be changed on the PEP. If one does not
want it to run on the baseclass, a simple default argument and an `if
param is None: return` on the method body can do the job, with less
exceptions and surprises.

Otherwise, I'd suggest at least some PEP rewording to make explicit
the fact it is not run on the class it is defined at all.  (I can help
with that, but I'd rather see it implemented as above).

I can see the fact that it woudl have little effect, as any eventual
parameter on the Base class could be hardcoded into the class body
itself - but just imagine a  class hierarchy with cooperative
"__init_subclass__"  methods - it would be rather surprising that each
class has to count on its parents __init_subclass__ being run, without
the one defined in its own body being called - that is rather
surprising.

---
2)
I have another higher level concern with the PEP as well:
It will pass all class keyword parameters, but for "metaclass" to
"__init_subclass__" - thus making it all but impossible to any other
keyword to the class creation machinery to ever be defined again. We
can't think of any such other keyword now, but what might come in a
couple of years?


What about just denoting in the PEP that "double under" keywords
should be reserved and not relied to not be used by "type" itself in
the future? (or any other way of marking reserved class kewyords)  -
actually it would even make sense to make "__metaclass__" an alias for
"metaclass" in the class creation machinery.

Anyway the PEP itself should mention that currently the keyword-arg
"metaclass" is swallowed by the class creation machinery and will
never reach `__init_subclass__` - this behavior is less surprising for
me, but it should be documented)

Or, an  even less exceptional behavior  for the future: make it so
that "metaclass"  specifies a custom metaclass (due to compatibility
issues) AND is passed to __init_subclass__, and  "__metaclass__"
specifies a metaclass and is not passed (along with  other
double-unders as they are defined)).

(as an extra bonus, people migrating from Python 2 to Python 3.6 will
not even be surprised by the keyword argument being __metaclass__)

Best regards,

js
  -><-

On 25 July 2016 at 00:49, Nick Coghlan  wrote:
> On 25 July 2016 at 03:00, Guido van Rossum  wrote:
>> Yes.
>
> OK, we can cover that in the documentation - if folks want to emulate
> what happens during class construction after the fact, they'll need to
> do:
>
> cls.name = attr
> attr.__set_name__(cls, "name")
>
> Semantically, I agree that approach makes sense - by default,
> descriptors created outside a class body won't have a defined owning
> class or attribute name, and if you want to give them one, you'll have
> to do it explicitly.
>
> 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/jsbueno%40python.org.br
___
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] PEP487: Simpler customization of class creation

2016-07-27 Thread Joao S. O. Bueno
On 27 July 2016 at 22:30, Nick Coghlan  wrote:
> On 28 July 2016 at 03:56, Joao S. O. Bueno  wrote:
>> Otherwise, I'd suggest at least some PEP rewording to make explicit
>> the fact it is not run on the class it is defined at all.  (I can help
>> with that, but I'd rather see it implemented as above).
>
> This is covered in the PEP:
> https://www.python.org/dev/peps/pep-0487/#calling-the-hook-on-the-class-itself
>
>> 2)
>> I have another higher level concern with the PEP as well:
>> It will pass all class keyword parameters, but for "metaclass" to
>> "__init_subclass__" - thus making it all but impossible to any other
>> keyword to the class creation machinery to ever be defined again. We
>> can't think of any such other keyword now, but what might come in a
>> couple of years?
>
> This isn't a new problem, as it already exists today for custom
> metaclasses. It just means introducing new class construction keywords
> at the language level is something that needs to be handled
> judiciously, and with a view to the fact that it might have knock-on
> effects for other APIs which need to find a new parameter name.
>

Actually, as documented on the PEP (and I just confirmed at a Python
3.5 prompt),
you actually can't use custom keywords for class defintions. This PEP
fixes that, but at the same time makes any other class reserved
keyword impossible in the future - that is, unless a single line
warning against reserved name patterns is added. I think it is low a
cost not to be paid now, blocking too many - yet to be imagined -
future possibilities.


(as for the example in Py 3.5):

In [17]: def M(type):
   ...: def __new__(metacls, name, bases, dict, **kw):
   ...: print(kw)
   ...: return super().__new__(name, bases, dict)
   ...: def __init__(cls, name, bases, dict, **kw):
   ...: print("init...", kw)
   ...: return super().__init__(name, bases, dict)
   ...:

In [18]: class A(metaclass=M, test=23, color="blue"):
   ...: pass
   ...:
---
TypeError Traceback (most recent call last)
 in ()
> 1 class A(metaclass=M, test=23, color="blue"):
 2 pass

TypeError: M() got an unexpected keyword argument 'color'

> Regards,
> 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] PEP487: Simpler customization of class creation

2016-07-28 Thread Joao S. O. Bueno
On 28 July 2016 at 04:26, Nick Coghlan  wrote:
> On 28 July 2016 at 13:55, Joao S. O. Bueno  wrote:
>> Actually, as documented on the PEP (and I just confirmed at a Python
>> 3.5 prompt),
>> you actually can't use custom keywords for class defintions. This PEP
>> fixes that, but at the same time makes any other class reserved
>> keyword impossible in the future - that is, unless a single line
>> warning against reserved name patterns is added.
>
> We don't warn against people defining new dunder-protocols as methods,
> why would we warn against a similar breach of convention in this case?
> I'm also wondering how you would want such a warning to work if we
> ever claimed a parameter name for a base class in the standard
> library, but didn't claim it as a name supported by type/object.
>
> Note that I'm not denying that it *may* be annoying *if* we define a
> new universal class parameter at some point in the future *and* it
> collides with a custom parameter in a pre-existing API *and* the
> authors of that API miss the related PEP.
>
> However, given that we've come up with exactly one named class
> parameter to date (metaclass), and explicitly decided against adding
> another (namespace, replaced with PEP 520's simpler option of just
> making the standard namespace provide attribute ordering data), the
> odds of actually encountering the posited problematic scenario seem
> pretty remote.

That is alright.
(Even though, I think somewhere around there are remarks against one
putting forth his own dunder methods) .

But that elaves another issue open: the "metaclass" parameter get in
to a very odd position, in which it has nothing distinctive about it,
still is the only parameter that will be swallowed and won't reach
"__init_subclass__".

 Although I know it is not straightforward to implement (as the
"metaclass" parameter is not passed to the metaclass __new__ or
__init__), wouldn't it make sense to make it be passed to
__init_subclass__ just like all other keywords?  (the default
__init_subclass__ then could swallow it, if it reaches there).


I am putting the question now, because it is a matter of "now" or
"never" - I can see it can does make sense if it is not passed down.

Anyway, do you have any remarks on the first issue I raised? About
__init_subclass__ being called in the class it is defined in, not just
on it's descendant subclasses?


>
> Regards,
> 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] PEP487: Simpler customization of class creation

2016-07-28 Thread Joao S. O. Bueno
On 28 July 2016 at 10:53, Nick Coghlan  wrote:
> On 28 July 2016 at 23:12, Joao S. O. Bueno  wrote:
>>  Although I know it is not straightforward to implement (as the
>> "metaclass" parameter is not passed to the metaclass __new__ or
>> __init__), wouldn't it make sense to make it be passed to
>> __init_subclass__ just like all other keywords?  (the default
>> __init_subclass__ then could swallow it, if it reaches there).
>>
>> I am putting the question now, because it is a matter of "now" or
>> "never" - I can see it can does make sense if it is not passed down.
>
> It would complicate the implementation, and has the potential to be
> confusing (since the explicit metaclass hint and the actual metaclass
> aren't guaranteed to be the same), so I don't think it makes sense to
> pass it down. I'll make sure we note it in the documentation for the
> new protocol method, though.
>
>> Anyway, do you have any remarks on the first issue I raised? About
>> __init_subclass__ being called in the class it is defined in, not just
>> on it's descendant subclasses?
>
> That's already covered in the PEP:
> https://www.python.org/dev/peps/pep-0487/#calling-the-hook-on-the-class-itself
>
> We want to make it easy for mixin classes to use __init_subclass__ to
> define "required attributes" on subclasses, and that's straightforward
> with the current definition:
>
> class MyMixin:
> def __init_subclass__(cls, **kwargs):
> super().__init_subclass__(**kwargs)
> if not hasattr(cls, "mixin_required_attribute"):
> raise TypeError(f"Subclasses of {__class__} must
> define a 'mixin_required_attribute' attribute")
>
> If you actually do want the init_subclass__ method to also run on the
> "base" class, then you'll need to tweak the class hierarchy a bit to
> look like:
>
> class _PrivateInitBase:
> def __init_subclass__(cls, **kwargs):
> super().__init_subclass__(**kwargs)
> ...
>
> def MyOriginalClass(_PrivateInitBase):
> ...
>
> (You don't want to call __init_subclass__ from a class decorator, as
> that would call any parent __init_subclass__ implementations a second
> time)
>
> By contrast, when we had the default the other way around, opting
> *out* of self-application required boilerplate inside of
> __init_subclass__ to special case the situation where "cls is
> __class__":
>
> class MyMixin:
> def __init_subclass__(cls, **kwargs):
> super().__init_subclass__(**kwargs)
> if cls is __class__:
> return # Don't init the base class
> if not getattr(cls, "mixin_required_attribute", None) is None:
> raise TypeError(f"Subclasses of {__class__} must
> define a non-None 'mixin_required_attribute' attribute")
>
> This raises exciting new opportunities for subtle bugs, like bailing
> out *before* calling the parent __init_subclass__ method, and then
> figure out that a later error from an apparently unrelated method is
> because your __init_subclass__ implementation is buggy.
>
> There's still an opportunity for bugs with the current design decision
> (folks expecting __init_subclass__ to be called on the class defining
> it when that isn't the case), but they should be relatively shallow
> ones, and once people learn the rule that __init_subclass__ is only
> called on *strict* subclasses, it's a pretty easy behaviour to
> remember.

Thanks for the extensive reasoning.

Maybe then adding a  `run_init_subclass` class decorator on the stdlib
to go along with the pep?
It should be a two liner that would avoid boiler plate done wrong -
but more important than thatm is that it being documented alog with
the __init_sublass__ method will make it more obvious it is not run
where it is defined. (I had missed it in the PEP text and just
understood that part when re-reading the PEP after being surprised)

  js
 -><-

>
> 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] Exact date of Python 2 EOL?

2017-03-23 Thread Joao S. O. Bueno
On 23 March 2017 at 19:47, Barry Warsaw  wrote:
> On Mar 23, 2017, at 08:02 PM, MRAB wrote:
>
>>If you see 2/8, is that 2 August or February 8?
>
> I think that's 0.25 which doesn't look like a date to me .  ISO 8601
> dates please: 2020-02-08 is unambiguous.

In Python 2, 2/8 is just 0.
>
> -Barry
> ___
> 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/jsbueno%40python.org.br
___
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 warning at startup: please remove it

2017-06-12 Thread Joao S. O. Bueno
On 12 June 2017 at 14:24, Nick Coghlan  wrote:
> On 12 June 2017 at 18:56, Victor Stinner  wrote:
>> Hi,
>>
>> Nick Coghlan pushed his implementation of his PEP 538: nice! Nice step
>> forward to UTF-8 everywhere ;-)
>>
>> I would prefer to not be annoyed by warning messages about encodings
>> at startup if possible:
>>
>> "Python detected LC_CTYPE=C: LC_CTYPE coerced to C.UTF-8 (set another
>> locale or PYTHONCOERCECLOCALE=0 to disable this locale coercion
>> behavior)."
>
> Note that there's an open issue for this linked from the What's New entry:
>
> * 
> https://docs.python.org/dev/whatsnew/3.7.html#pep-538-legacy-c-locale-coercion
> * https://bugs.python.org/issue30565
>
> I suspect the eventual outcome is going to be dropping that particular
> warning (since it's been problematic for Fedora's 3.6 backport as
> well, and the problems are due to the warning itself, *not* the locale
> coercion), but I'd prefer to keep the notification at least for a
> while (potentially even until alpha 1).
>
> OTOH, I'm also open to being persuaded otherwise if enough folks are
> running into problems with it just while working on CPython (I'd still
> like to turn it back on for alpha 1 even if we turn off in the
> meantime, though).
>
> Cheers,
> Nick.
>
> P.S. Part of my rationale for doing it this way is that I'm certain
> that after 3.7's release next year we're going to get at least a few
> users genuinely upset at our decision to move the ASCII-based C locale
> explicitly into the "legacy partially-supported environment" category,
> and even more upset that we're "silently ignoring their explicit
> configuration settings" by implicitly coercing it to something else.


Yes - all these 15 users can be quite noisy - they are not quite users of
"whatever there is is good" like the other 800 million or so users
that will be bothered by
the warning.
(Ok -  I guess most of the 800 million users won't even be seeing a
terminal when running their Python -
but still it would be a  couple million users and let's suppose there
are 150 and not 15 genuinely worried
about that coercion)


>
> Those kinds of concerns are much easier to address effectively if we
> can say "We tried it with an explicit warning, and it was too annoying
> to be usable; see  if you want more details" than if we're
> in the situation of having to say "We assumed an explicit warning
> would be too annoying, so we never even tried it".

Perfect - and guess what? It looks like it already happened, as you
can see by these e-mail messages.
Therefore we are good to remove the warning now.

>
>
> --
> 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/jsbueno%40python.org.br
___
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] Impact of Namedtuple on startup time

2017-07-17 Thread Joao S. O. Bueno
Just for sake of completeness  since people are talking about a namedtuple
overhaul, I have a couple implementations here -

https://github.com/jsbueno/extradict/blob/master/extradict/extratuple.py

If any idea there can help inspiring someone, I will be happy.

  js
 -><-

On 17 July 2017 at 18:26, Barry Warsaw  wrote:

> namedtuple is great and clever, but it’s also a bit clunky.  It has a
> weird signature and requires a made up type name.  It’s also rather
> unPythonic if you want to support default arguments when creating
> namedtuple instances.  Maybe as you say, a lot of the typical use cases for
> namedtuples could be addressed by a better builtin, but I fear we’ll end up
> down the bikeshedding hole for that.
>
> -Barry
>
> > On Jul 17, 2017, at 16:31, Giampaolo Rodola'  wrote:
> >
> > I completely agree. I love namedtuples but I've never been too happy
> about the additional overhead vs. plain tuples (both for creation and
> attribute access times), to the point that I explicitly avoid to use them
> in certain circumstances (e.g. a busy loop) and only for public end-user
> APIs returning multiple values.
> >
> > To be entirely honest, I'm not even sure why they need to be forcefully
> declared upfront in the first place, instead of just having a first-class
> function (builtin?) written in C:
> >
> > >>> ntuple(x=1, y=0)
> > (x=1, y=0)
> >
> > ...or even a literal as in:
> >
> > >>> (x=1, y=0)
> > (x=1, y=0)
> >
> > Most of the times this is what I really want: quickly returning an
> anonymous tuple with named attributes and nothing else, similarly to
> os.times() & others. I believe that if something like this would exist we
> would witness a big transition from tuple() to ntuple() for all those
> functions returning more than 1 value. We witnessed a similar transition in
> many parts of the stdlib when collections.namedtuple was first introduced,
> but not everywhere, probably because declaring a namedtuple is more work,
> it's more expensive, and it still feels like you're dealing with some kind
> of too high-level second-class citizen with too much overhead and too many
> sugar in terms of API (e.g. "verbose", "rename", "module" and "_source").
>
>
> ___
> 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/
> jsbueno%40python.org.br
>
>
___
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] deque implementation question

2017-07-18 Thread Joao S. O. Bueno
On 15 July 2017 at 04:01, Max Moroz  wrote:

> What would be the disadvantage of implementing collections.deque as a
> circular array (rather than a doubly linked list of blocks)? My naive
> thinking was that a circular array would maintain the current O(1) append/pop
> from either side, and would improve index lookup in the middle from O(n) to
> O(1). What am I missing?
>
> The insertion/removal of an arbitrary item specified by a pointer would
> increase from constant time to linear, but since we don't have pointers
> this is a moot point.
>
> Of course when the circular array is full, it will need to be reallocated,
> but the amortized cost of that is still O(1). (Moreover, for a bounded
> deque, there's even an option of preallocation, which would completely
> eliminate reallocations.)
>

Now - since you are at it,  you could possibly mine pypi for interesting
efficient data structures that could cover use cases lists and deque not
suffice. I am pretty sure one could find a couple,  - and once we get a few
that are well behaved and somewhat popular, they could be made candidates
for inclusion in collections, I guess.



> Thanks
>
> Max
>
> ___
> 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/
> jsbueno%40python.org.br
>
>
___
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 550 module

2017-08-28 Thread Joao S. O. Bueno
Well, this talk may be a bit of bike-shedding, but

+1 for a separate module/sub module

And full -1 for something named

"dynscopevars"

That word is unreadable, barely mnemonic, but plain "ugly" - (I know that
this is  subjective, but it is just that :-) )

Why not just "execution_context"  or "sys.execution_context" ?

"from execution_context import Var, lookup, set, LogicalContext, run_with  "






On 27 August 2017 at 12:51, Jim J. Jewett  wrote:

> I think there is general consensus that this should go in a module other
> than sys. (At least a submodule.)
>
> The specific names are still To Be Determined, but I suspect seeing the
> functions and objects as part of a named module will affect what works.
>
> So I am requesting that the next iteration just pick a module name, and
> let us see how that looks.  E.g
>
> import dynscopevars
>
> user=dynscopevars.Var ("username")
>
> myscope=dynscopevars.get_current_scope()
>
> childscope=dynscopevars.Scope (parent=myscope,user="bob")
>
>
> -jJ
>
>
> ___
> 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/
> jsbueno%40python.org.br
>
>
___
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] Re: PEP 674: Disallow using macros as l-value

2021-12-07 Thread Joao S. O. Bueno
Sorry for stepping in - but I am seeing too many arguments in favour
of the rules because "they are the rules", and just Victor arguing with
what is met in the "real world".

But if this update can be done by a simple search/replace on the C source
of projects,
I can only perceive two scenarios this will affect: well maintained
projects,
 for which it is fixable in minutes, and  stale packages, no longer
released
that "happen to work" when someone downloads and builds for new
Python versions. In these cases, the build will fail. If the person trying
the build can't fix it, but can take the error to a proper, or high
visibility,
forum, someone will be able to come to the fix, leading to renewed
visibility for the otherwise stale package.



On Tue, 7 Dec 2021 at 12:40, Antoine Pitrou  wrote:

> On Tue, 7 Dec 2021 15:39:25 +0100
> Petr Viktorin  wrote:
>
> > On 30. 11. 21 19:52, Victor Stinner wrote:
> > > On Tue, Nov 30, 2021 at 7:34 PM Guido van Rossum 
> wrote:
> > >> How about *not* asking for an exception and just following the PEP
> 387 process? Is that really too burdensome?
> > >
> > > The Backward Compatibility section gives an explanation:
> > >
> > > "This change does not follow the PEP 387 deprecation process. There is
> no
> > > known way to emit a deprecation warning when a macro is used as a
> > > l-value, but not when it's used differently (ex: r-value)."
> > >
> > > Apart of compiler warnings, one way to implement the PEP 387
> > > "deprecation process" would be to announce the change in two "What's
> > > New in Python 3.X?" documents. But I expect that it will not be
> > > efficient. Extract of the Rejected Idea section:
> > >
> > > "(...) only few developers read the documentation, and only a minority
> > > is tracking changes of the Python C API documentation."
> > >
> > > In my experience, even if a DeprecationWarning is emitted at runtime,
> > > developers miss or ignore it. See the recent "[Python-Dev] Do we need
> > > to remove everything that's deprecated?" discussion and complains
> > > about recent removal of deprecated features, like:
> > >
> > > * collections.MutableMapping was deprecated for 7 Python versions
> > > (deprecated in 3.3) -- removed in 3.9 alpha, reverted in 3.9 beta,
> > > removed again in 3.11
> > > * the "U" open() flag was deprecated for 10 Python versions
> > > (deprecated in 3.0) -- removed in 3.9 alpha, reverted in 3.9 beta,
> > > removed again in 3.11
> > >
> > > For this specific PEP changes, I consider that the number of impacted
> > > projects is low enough to skip a deprecation process: only 4 projects
> > > are known to be impacted. One year ago (Python 3.10), 16 were
> > > impacted, and 12 have already been updated in the meanwhile. I'm
> > > talking especially about Py_TYPE() and Py_SIZE() changes which, again,
> > > has been approved by the Steering Council.
> >
> >
> > The current version of the PEP looks nice, but I don't think the
> > rationale is strong enough.
> > I believe we should:
> > - Mark the l-value usage as deprecated in the docs,
> > - And then do nothing until we find an actual case where this issue
> > blocks development (or is actively dangerous for users).
>
> Is there a way to emit a compilation warning when those macros are used
> as l-values? Even if only enabled on some compilers.
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/YMMRRVVYIS6PJR3WTKLYDFY3XJ3UAKW3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WNTZZYLT3VK6REJ3BEBVGNDGZCIXWFCA/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Function Prototypes

2021-12-23 Thread Joao S. O. Bueno
My eyes are bleeding with these incomplete function definitions.
If you are using decorators and "def", then, please, there is  no
need for special syntax that would just be a syntax error
in "normal"Python., Just add ": pass" to the end.

If eyes bleeding is not enough of an argument for you:
the new syntax would only be possible be usable in code
that would run on Python 3.11 and above. While using
the decorator + function declaration syntax, you have the
annotations that could readly be checked and code compatible with
existing all supported Python versions, right out of the box.

On Thu, 23 Dec 2021 at 16:31, MRAB  wrote:

> On 2021-12-23 19:04, asleep.c...@gmail.com wrote:
> > Hello and thank you for the much needed feedback.
> >
> > One thing that you must consider is that function prototypes
> > have a few implications beyond typing but it seems like you're
> > only looking at it as a tool for type hinting. The interpreter will
> > create a function prototype object regardless of if you forget your
> > decorator, it needs to pass something to the decorator after all.
> >
> > After reading through your reply, I am seeing that the main concern
> > is the bloat added by the lambda keyword. My decision to use lambda
> > instead of introducing a special syntax was one that required heavy
> > deliberation. I ultimately decided to stick with lambda because it was
> > consistent with the prototype statement form. The fact that lambda
> > is hard to type has been felt by almost everyone who has ever used
> > Python, this isn't just a problem that would be introduced by
> > function prototypes. PEP 677 has taken the lazy approach to solving
> > this issue and has prioritized type hinting over functionality. PEP 667
> > also suggests the usage of => for lambdas which would likely
> > never be accepted because of the confusion it would cause.
> > As someone who has used typing with Python, I do think that a new
> > callable syntax is needed, but I truly believe that PEP 677 is taking the
> > wrong approach.
> >
> > So what if we broke every Python program in existence by creating a
> > new lambda syntax, how would it look? This question is particularly
> > hard to answer because the body and annotations both need to be
> > optional. Our best bet is an augmented form of the PEP 677 syntax
> > that allows you to add a body. Here is an example:
> >
> > (a: int) -> int: a ** 2
> >
> > But of course this causes ambiguity when the return annotation and
> > body are both omitted. One thing that I did consider is simply treating
> > it like a tuple if there is no return annotation AND there is no body,
> but
> > that might lead to confusion. Another thing that I considered is a
> different
> > prefix than lambda:
> >
> > $(a: int) -> int: a ** 2
> >
> Usually the suggestion is to use 'def':
>
>  def (a: int) -> int: a ** 2
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/AKS4IHJJFDV24QZNMVMFZR72H5ORU3TB/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BGQUJQCBW72WDGRKXT5JXKS2AEBS36OJ/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 679 – Allow parentheses in assert statements

2022-01-10 Thread Joao S. O. Bueno
On Mon, 10 Jan 2022 at 08:39, Victor Stinner  wrote:

> Does someone know if linters like pylint or pylakes current warn on
> "assert(test, msg)" statements?
>
> If a project use such assertions which are always true, they can start
> failing wit the PEP 679, right?


OTOH, any assertion which start failing in this way, is a statement which
_should_ have been failing from the start, and was being ignored up to
this change.

While it can indeed, make otherwise stable projects with "nop"s assert
sudden failing, that should be a trivial fix for any non-unmaintained
project.

+1 to the change




> Hopefully, the fix is easy: removing
> the parenthesis give the same behavior on old and new Python versions.
>
> (it will behave the same just if the first expression is actually truish)


> Is it possible to run a code search on PyPI top 5000 projects to see
> if such always-true assertion is common or not?
>
> Victor
>
> On Mon, Jan 10, 2022 at 1:22 AM Pablo Galindo Salgado
>  wrote:
> >
> > Hi everyone,
> >
> > I would like to start a discussion about a small PEP proposal to allow
> parentheses in
> > assert statements to fix a common gotcha with assert statements.
> >
> > Link to the PEP: https://www.python.org/dev/peps/pep-0679/
> >
> > Please, redirect all discussions to:
> >
> >
> https://discuss.python.org/t/pep-679-allow-parentheses-in-assert-statements/13003
> >
> > as I will not be monitoring answers to this thread.
> >
> > Thanks, everyone for your time!
> >
> > Regards from cloudy London,
> > Pablo Galindo Salgado
> > ___
> > Python-Dev mailing list -- python-dev@python.org
> > To unsubscribe send an email to python-dev-le...@python.org
> > https://mail.python.org/mailman3/lists/python-dev.python.org/
> > Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/I7MKCD3GHJXCERFCZ2FD3X7IPAX6ASVK/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> --
> Night gathers, and now my watch begins. It shall not end until my death.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/LFQGI43BH3SWKHRBPO7T3DC6SEU5HMQ3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/SFBWV5SAFYRFEASNJZJIRY4VUPIEOX24/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Restrict the type of __slots__

2022-03-18 Thread Joao S. O. Bueno
IMO this is a purism that have little, if any place in language
restrictions.
I see that not allowing. "run once" iterables could indeed void attempts to
write
"deliberatly non cooperative code" - but can it even be reliably detected?

The other changes seem just to break backwards compatibility for little or
no gain at all.



On Fri, Mar 18, 2022 at 6:57 AM Ronald Oussoren via Python-Dev <
python-dev@python.org> wrote:

>
>
> On 18 Mar 2022, at 10:29, Serhiy Storchaka  wrote:
>
> Currently __slots__ can be either string or an iterable of strings.
>
> 1. If it is a string, it is a name of a single slot. Third-party code
> which iterates __slots__ will be confused.
>
> 2. If it is an iterable, it should emit names of slots. Note that
> non-reiterable iterators are accepted too, but it causes weird bugs if
> __slots__ is iterated more than once. For example it breaks default
> pickling and copying.
>
> I propose to restrict the type of __slots__. Require it always been a
> tuple of strings. Most __slots__ in real code are tuples. It is rarely we
> need only single slot and set __slots__ as a string.
>
> It will break some code (there are 2 occurrences in the stdlib an 1 in
> scripts), but that code can be easily fixed.
>
>
> Pydoc supports __slots__ that is a dict, and will use the values in the
> dict als documentation for the slots.   I’ve also seen code using
> ``__slots__ =  “field1 field2”.split()``. I don’t particularly like this
> code pattern, but your proposal would break this.
>
> Also note that __slots__ only has a side effect during class definition,
> changing it afterwards is possible but has no effect (“class Foo: pass;
> Foo.__slots__ = 42”). This surprised my recently and I have no idea if this
> feature is ever used.
>
> Ronald
>
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/E32BRLAWOU5GESMZ5MLAOIYPXSL37HOI/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
> —
>
> Twitter / micro.blog: @ronaldoussoren
> Blog: https://blog.ronaldoussoren.net/
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/YQUWR7CYKNM65HR5FZQ3BANR5SNNK6N6/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/54XYWCLCXPM75LOGHPONKKRUKPUFKYQS/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

2022-04-23 Thread Joao S. O. Bueno
On Sat, Apr 23, 2022 at 7:10 PM Paul Moore  wrote:

> On Sat, 23 Apr 2022 at 22:42, Rob Cliffe via Python-Dev
>  wrote:
> >
> > UGH!
> >
> > I thought there was a general understanding that when typing was added
> > to Python, there would be no impact, or at least minimal impact, on
> > people who didn't use it.  (Raises hand.)
> > Now we see an(other) instance of intention creep.
>
> To be fair, none of this is needed unless you want to add type
> annotations to your code. So it's still perfectly possible to ignore
> all of this (which is what I am currently doing).
>
> What I am concerned about is when users of libraries I write start to
> claim that I "need" to add this sort of stuff to my code, so that they
> can type check their code that uses mine, and/or they can get tooltips
> for my APIs in their IDEs. That's where I think the biggest issue with
> a proposal like this arises - the *social* pressure on people to adopt
> typing, and all the complexities it adds. But again, that's not
> something that's specific to this proposal, it's inherent in the whole
> question of whether people add type annotations at all.
>
> So I'm -1 on this proposal, but just because I fear I may be forced to
> use it when I don't need to, rather than because I think it's a bad
> idea per se.
>
> Paul
>



I stand with Paul here -
But as a "heavy  user" of metaclasses, as far as that is possible.
(less in production code or "non toy projects", but a lot in
understanding what goes, answering questions and teaching people
on how they should best use (or skip using) a metaclass.
I'd say this breaks too much of the current working of class creation for,
possibly, too little.

And - on a second thought: Was not this the kind of thing that PEP 563 was
supposed to fix? Pep 563 is accepted now, I think one may just use a forward
declaration in any annotation context: it will be lazily evaluated and the
target
class will have been created.

So, while I understand the problem with forward references, which have
been historically workaround with the usage of strings (even long before
even Python 3.0, in Django's Models) I believe this is not a good approach


So first part:
==
I'd be comfortable with the statements and blocks as they are if the
"forward class" statement would not mess with the metaclass and
class creation at all: just create a place-holder the type checkers could
then
use to find the class later on the file, or later on the code, and then use
that class.

Has this been thought of? Is there any reason why that would not work,
better than
it will put some burden on static-type checkers, as opposed to
fundamentally modify the
way classes are built so that any library featuring any metaclass will have
to be divided in incompatible releases "before this pep" and "after this
pep"?
(and with the harsh inconvenience of needing to have one a part of the
code which is often the most complicated 100% rewritten)


Second part:
=

The proposal as it is does not preserve everything that is possible with
the current metaclass "__new__", besides complicating things.
Moreover, there _are_ similar steps on "breaking metaclass.`__new__` " that
would actually be useful in customizing the way classes are created,
without sacrificing compatibility (in a sense the custom
"metaclass.__new__"
would still be called exactly as it is today).

If there is any chance this thing will move on, I'd like to detail these
ideas
(it would be longish, similar in size with the proto-pep text) - and maybe
there is a
way to reconcile compatibility, without the  proposal of splitting
"__new__"
in two 100% incompatible methods.

I will leave the actual amendments to this part of the proposal
(which would affect all the inner workings of the metaclasses as exposed)
to another message. But I will leave one first, huge,  problem here that:


```Python
 def __new_forward__(metaclass, name, bases, namespace, **kwargs):

 def __new_continue__(metaclass, cls, **kwargs):
```

These two, as they are, do not allow for some of the things that are
possible today:
let's supose I want, in a custom metaclass `__new__` method inspect the
namespace and creates a "__slots__" declaration based on what already _is_
 on the namespace: in "__new_forward__" the namespace is filled in a non
deterministic way and should
 not be inspected , and in "__new_continue__" it had already been
processed by (what currently is) "type.__new__" and baked into the
proxy-map
inside the "cls". I the specific case of creating "__slots__" in a similar
way "@dataclass"
does, the oportunity is gone.

I won't mention the suggestion in the text that "class transformers that
would
create slots are free to re-create the class object upon its first
instantiation"
is _rather_  bogus. I can imagine a metaclass "__call__" method that could
do
that, but then, the classes the instances would be actually using  would
rather
become either have to be kept as an attribute in the cl

[Python-Dev] Re: Proto-PEP part 2: Alternate implementation proposal for "forward class" using a proxy object

2022-04-23 Thread Joao S. O. Bueno
TL;DR
(literally, I will go back and read it now, but after reading the first
paragraphs:
_a proxy_  object yes, then dividing class creation in 2 blocks would
not break things)

/me goes back to text.


On Fri, Apr 22, 2022 at 10:20 PM Larry Hastings  wrote:

>
> Here's one alternate idea for how to implement the "forward class" syntax.
>
> The entire point of the "forward class" statement is that it creates
> the real actual class object.  But what if it wasn't actually the
> "real" class object?  What if it was only a proxy for the real object?
>
> In this scenario, the syntax of "forward object" remains the same.
> You define the class's bases and metaclass.  But all "forward class"
> does is create a simple, lightweight class proxy object.  This object
> has a few built-in dunder values, __name__ etc.  It also allows you
> to set attributes, so let's assume (for now) it calls
> metaclass.__prepare__ and uses the returned "dict-like object" as
> the class proxy object __dict__.
>
> "continue class" internally performs all the rest of the
> class-creation machinery.  (Everything except __prepare__, as we
> already called that.)  The first step is metaclass.__new__, which
> returns the real class object.  "continue class" takes that
> object and calls a method on the class proxy object that says
> "here's your real class object".  From that moment on, the proxy
> becomes a pass-through for the "real" class object, and nobody
> ever sees a reference to the "real" class object ever again.
> Every interaction with the class proxy object is passed through
> to the underlying class object.  __getattribute__ calls on the
> proxy look up the attribute in the underlying class object.  If
> the object returned is a bound method object, it rebinds that
> callable with the class proxy instead, so that the "self" passed
> in to methods is the proxy object.  Both base_cls.__init_subclass__
> and cls.__init__ see the proxy object during class creation.  As far
> as Python user code is concerned, the class proxy *is* the class,
> in every way, important or not.
>
> The upside: this moves all class object creation code into "continue
> class" call.  We don't have to replace __new__ with two new calls.
>
> The downside: a dinky overhead to every interaction with a "forward
> class" class object and with instances of a "forward class" class
> object.
>
>
> A huge concern: how does this interact with metaclasses implemented
> in C?  If you make a method call on a proxy class object, and that
> calls a C function from the metaclass, we'd presumably have to pass
> in the "real class object", not the proxy class object.  Which means
> references to the real class object could leak out somewhere, and
> now we have a real-class-object vs proxy-class-object identity crisis.
> Is this a real concern?
>
>
> A possible concern: what if metaclass.__new__ keeps a reference to
> the object it created?  Now we have two objects with an identity
> crisis.  I don't know if people ever do that.  Fingers crossed that
> they don't.  Or maybe we add a new dunder method:
>
>  @special_cased_staticmethod
>  metaclass.__bind_proxy__(metaclass, proxy, cls)
>
> This tells the metaclass "bind cls to this proxy object", so
> metaclasses that care can update their database or whatever.
> The default implementation uses the appropriate mechanism,
> whatever it is.
>
> One additional probably-bad idea: in the case where it's just a
> normal "class" statement, and we're not binding it to a proxy,
> should we call this?
>
>  metaclass.__bind_proxy__(metaclass, None, cls)
>
> The idea there being "if you register the class objects you create,
> do the registration in __bind_proxy__, it's always called, and you'll
> always know the canonical object in there".  I'm guessing probably not,
> in which case we tell metaclasses that track the class objects we
> create "go ahead and track the object you return from __new__, but
> be prepared to update your tracking info in case we call __bind_proxy__
> on you".
>
>
> A small but awfully complicated wrinkle here: what do we do if the
> metaclass implements __del__?  Obviously, we have to call __del__
> with the "real" class object, so it can be destroyed properly.
> But __del__ might resurrect that object, which means someone took a
> reference to it.
>
>
>
> One final note.  Given that, in this scenario, all real class creation
> happens in "continue class", we could move the bases and metaclass
> declaration down to the "continue class" statement.  The resulting
> syntax would look like:
>
>  forward class X
>
>  ...
>
>  continue class X(base1, base2, metaclass=AmazingMeta,
> rocket="booster")
>
> Is that better? worse? doesn't matter?  I don't have an intuition about
> it right now--I can see advantages to both sides, and no obvious
> deciding factor.  Certainly this syntax prevents us from calling
> __prepare__ so early, so we'd have to use a real dict in the "forward
> class" proxy ob

[Python-Dev] Re: Proto-PEP part 2: Alternate implementation proposal for "forward class" using a proxy object

2022-04-23 Thread Joao S. O. Bueno
So -

good idea on creating the proxy.

But would you really __need__ this badly that the
proxy object would "become" the new class object,
preserving its "id"?

Just name re-binding
(and the static type checkers _knowing_ the name
will be re-assign to the actuall class object later) seems
to be pretty straightforward, and would break too little.

If one assigns the proxy to a different name in the meantime,
and keep a reference to it: "consenting adults" apply: one just
got a somewhat useless stub object to play along with.

Ok, it would be more of a "stub" object than a "proxy" object,


So, if the  "proxy" is really needed - there is one type
of existing proxy to classes in Python that is really transparent,
and that is not easily creatable by Python code -
those are the instances of "super()"  - the will
answer proper even to isinstance and issubclass calls,
as it goes beyond what is possible by customizing
__getattribute__.  So, if a proxy is really needed
instead of a simple name rebind, probably the existing
code for "super' can be reused for them.

As for: "do people keep references for the classes
inside "__new__"? - Yes, all the time.
The "__bind_proxy__" method you describe would
again break compatibility (although in a much
more reasonable way than the "__new__" split.)
But then, the re-binding, if any, could take place
inside "type.__new__", before it returns
the newly created "cls" to the call to it made
inside the custom metaclass.__new__ .
Some code might break when getting back a proxied
class at this point, but, up to that point, a lot of code
could also break with this kind of proxies - "super()" instances work well
but there are, of course, lots of corner cases.
All in all, I think this is overkill for the problem at hand.

As I wrote before: I stand with what Paul Moore wrote:
in an ideal universe annotations  for type checking should
be optional. In the real world, there is a lot of pressure,
surging from everywhere, for strict type-checking in
all types of projects, open source or not, and I find
this a very sad state of things. Breaking the language
compatibility and features because it is needed
for "optional" type checking is sad-squared.


On Fri, Apr 22, 2022 at 10:20 PM Larry Hastings  wrote:

>
> Here's one alternate idea for how to implement the "forward class" syntax.
>
> The entire point of the "forward class" statement is that it creates
> the real actual class object.  But what if it wasn't actually the
> "real" class object?  What if it was only a proxy for the real object?
>
> In this scenario, the syntax of "forward object" remains the same.
> You define the class's bases and metaclass.  But all "forward class"
> does is create a simple, lightweight class proxy object.  This object
> has a few built-in dunder values, __name__ etc.  It also allows you
> to set attributes, so let's assume (for now) it calls
> metaclass.__prepare__ and uses the returned "dict-like object" as
> the class proxy object __dict__.
>
> "continue class" internally performs all the rest of the
> class-creation machinery.  (Everything except __prepare__, as we
> already called that.)  The first step is metaclass.__new__, which
> returns the real class object.  "continue class" takes that
> object and calls a method on the class proxy object that says
> "here's your real class object".  From that moment on, the proxy
> becomes a pass-through for the "real" class object, and nobody
> ever sees a reference to the "real" class object ever again.
> Every interaction with the class proxy object is passed through
> to the underlying class object.  __getattribute__ calls on the
> proxy look up the attribute in the underlying class object.  If
> the object returned is a bound method object, it rebinds that
> callable with the class proxy instead, so that the "self" passed
> in to methods is the proxy object.  Both base_cls.__init_subclass__
> and cls.__init__ see the proxy object during class creation.  As far
> as Python user code is concerned, the class proxy *is* the class,
> in every way, important or not.
>
> The upside: this moves all class object creation code into "continue
> class" call.  We don't have to replace __new__ with two new calls.
>
> The downside: a dinky overhead to every interaction with a "forward
> class" class object and with instances of a "forward class" class
> object.
>
>
> A huge concern: how does this interact with metaclasses implemented
> in C?  If you make a method call on a proxy class object, and that
> calls a C function from the metaclass, we'd presumably have to pass
> in the "real class object", not the proxy class object.  Which means
> references to the real class object could leak out somewhere, and
> now we have a real-class-object vs proxy-class-object identity crisis.
> Is this a real concern?
>
>
> A possible concern: what if metaclass.__new__ keeps a reference to
> the object it created?  Now we have two objects with an identity
> crisis.  I don't know if peo

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

2022-04-24 Thread Joao S. O. Bueno
I am not worried about the bikeshed part of which syntax to use -
and more worried with the possible breaking of a lot of stuff, unless
we work with creation of a non-identical "forward object" that is
rebound, as in plain name binding, when the second part
is declared. I've stated that amidst my ramblings,
but Nick Coghlan managed to keep it suscint at
https://mail.python.org/archives/list/python-dev@python.org/message/DMITVTUIQKJW6RYVOPQXHD54VSYE7QHA/

"""
Something worth considering: whether forward references need to be
*transparent* at runtime. If they can just be regular ForwardRef objects
then much of the runtime complexity will go away (at the cost of some
potentially confusing identity check failures between forward references
and the actual class objects).

ForwardRef's constructor could also potentially be enhanced to accept a
"resolve" callable, and a "resolve()" method added to its public API,
although the extra complexity that would bring may not be worth it.

Cheers,
Nick.

"""

For that matter, syntax wise, it could just be:

break class XX()

...

continue class XX:
...

It gains at once no backwards incompatibility, and reuse concepts that
are already somewhat "grouped together".

On Sun, Apr 24, 2022 at 11:25 AM Eric V. Smith  wrote:

> On 4/24/2022 5:42 AM, Stephen J. Turnbull wrote:
> > What's the use case for arbitrary expressions vs. a (possibly
> > qualified) name?  A class factory that produces forward declarations?
> > Do you have a use case in mind?
>
> It's:
>
> x.py:
>
> --8<
> forward class A()
> --8<
>
> x_impl.py
>
> --8<
> import X
>
> continue class X.A:
>  # class body here
> --8<
>
> It needs to be an expression because it's not defining a name, it
> referring to an existing name. You could use "from X import A" here and
> avoid a dotted expression, but it still needs to be an expression
> referring to an existing "forward class". Even if you restrict it to not
> having dots, it's logically an expression, not a name binding.
>
> Eric
>
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/VV53MWDTYQCHBCAQGXLZ4SFCKUEHPQ2K/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WBXIZLNKWTJGAQLTFJOOPFJ7VCD42U6D/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

2022-04-24 Thread Joao S. O. Bueno
I guess Carl's messages put an end to this proposal as it is.

>From "the language side", I can think of nothing short of actually
transforming _in place_ (like it is possible with instances of
ordinary classes when you assign then a new "__class__") the
"forward referenced object" into the complete classes.

This is not "unfeasable", but would be hackish as never before done,
and there are practical problems: the final size of the class object itself
cannot be known before the final committing of the class-body namespace
into the final-namespace (slots, and inheritance of built-in classes with
different layouts, etc...)

Then, it looks like it only would be remotely practical
for a static type checker if the class continuation is on the same
file as its header. (I think I did not even consider they
being in separate files - of course the name-rebinding
would not work in that case)

On the other hand, if it is practical to declare as header the complete
interface of a class, with the intent of putting the actual methods
with code later on, that is already possible, with typing.protocols ;
whoever would take the time to split a class in two due to annotations,
forward referencing, interface declaration separated from implementation,
can just as well declare a protocol, as it exists today,

I am not sure if typing.Protocol works nicely with inheritance, in the sense
that it could inherit from other protocols or concrete classes, and present
everything inherited as part of its interface, if it does not, then _that_
is the
improvement needed so that what this proto-pep would allow could be
done with them.

best regards,

   js
 -><-


On Sun, Apr 24, 2022 at 1:33 PM Carl Meyer  wrote:

> On Sun, Apr 24, 2022 at 10:20 AM Joao S. O. Bueno 
> wrote:
> >
> > I am not worried about the bikeshed part of which syntax to use -
> > and more worried with the possible breaking of a lot of stuff, unless
> > we work with creation of a non-identical "forward object" that is
> > rebound, as in plain name binding, when the second part
> > is declared. I've stated that amidst my ramblings,
> > but Nick Coghlan managed to keep it suscint at
> >
> https://mail.python.org/archives/list/python-dev@python.org/message/DMITVTUIQKJW6RYVOPQXHD54VSYE7QHA/
>
> I don't think name rebinding works. That means that if we have
> `forward class Bar` in module `foo` and `continue class Bar: ...` in
> module `foo.impl`, if module `baz` does `from foo import Bar`, it will
> forever have either the forward reference object or the real class,
> and which one it has is entirely unpredictable (depends on import
> ordering accidents of the rest of the codebase.) If `baz` happens to
> be imported before `foo.impl`, the name `Bar` in the `baz` namespace
> will never be resolved to the real class, and isn't resolvable to the
> real class without some outside intervention.
>
> > """
> > Something worth considering: whether forward references need to be
> > *transparent* at runtime. If they can just be regular ForwardRef objects
> > then much of the runtime complexity will go away (at the cost of some
> > potentially confusing identity check failures between forward references
> > and the actual class objects).
> >
> > ForwardRef's constructor could also potentially be enhanced to accept a
> > "resolve" callable, and a "resolve()" method added to its public API,
> > although the extra complexity that would bring may not be worth it.
> > """
>
> I'm not sure how this `resolve()` method is even possible under the
> proposed syntax. If `forward class Bar` and `continue class Bar` are
> in different modules, then how can `forward class Bar` (which must
> create the "forward reference" object) possibly know which module
> `continue class Bar: ...` exists in? How can it know how to resolve
> itself?
>
> Carl
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/US6OOS7OJMEZKQQC456LDRQKC2HRP72P/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

2022-04-25 Thread Joao S. O. Bueno
On Tue, Apr 26, 2022 at 12:33 AM Mehdi2277  wrote:

> The forward class annotations would not need need to be processed at
> runtime and could be no-ops.
>
> forward class A:
>   x: int
>   y: list[int]
>
>

So, as I"ve written before, since there seems to be no way out of Writing
Everything Twice
what about:

```
from typing import Protocol

class AProto(Protocol):
 x: int
 y: list[int]

 def distance(self, x: int, y: int) -> list[float]:
 ...

class B:
 value: AProto

class A(AProto):  #  inheriting from the protocol is optional, as per
PEP-544
x: int
y: list[int]

def distance(self, x: int, y: int) -> list[float]:
 # code for distance goes here
 ...
```

The best advantage of this particular bikeshed is that it makes
full use of Guido's Time Machine and is readily usable from Python 3.8
onwards!


A.__annotations__ could be empty. For a more complete example you could
> have,
>
> forward class A:
>   value: B # This annotation is solely for type checker and is not
> actually saved at runtime.
>
> class B:
>   value: A # Real annotation that is saved.
>
> continue class A:
>   value: B # Real annotation that is saved.
>
> The rule would then be that any annotation inside forward class is
> equivalent to a noop. Continue class would still need to have same
> annotation repeated to actually set it at runtime.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/O3HMCIWUM6NGTSCGL7HFRBSDT7A4KFHP/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3CIYJ43YQ5SCGO7M4LU2P6YCWNDV64DC/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

2022-04-26 Thread Joao S. O. Bueno
On Tue, Apr 26, 2022 at 9:55 AM Greg Ewing 
wrote:

> On 26/04/22 12:33 pm, Chris Angelico wrote:
> > That's exactly what I mean though: if the only difference between
> > "monkeypatching" and "not monkeypatching" is whether it was intended,
> > then the only difference is what you call it.
>
> No, it's not just a matter of what you call it.
>
> If I lose my keys and have to break into my house, it's not
> illegal. But if someone else breaks into my house without my
> permission, that is illegal. It doesn't matter if the thief
> *calls* it legal, there's still a difference.
>


MonkeyPatching in Python is not illegal in this sense.

As was put in this thread: let's not criminalize people
for mutating mutable objects.

btw, wether to call certain aspects of one of
the options for this proposal "monkeypatching" or not,
is a discussion that IMHO is far, far beyond bike-shedding.



>
> --
> Greg
>
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7HG35MGIE2HROG5LFIAIJH5IVGUUU32C/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Proto-PEP part 4: The wonderful third option

2022-04-26 Thread Joao S. O. Bueno
On Tue, Apr 26, 2022 at 4:04 AM  wrote:

> Larry Hastings wrote:
> > [...]
> >
> > Now comes the one thing that we might call a "trick".  The trick: when
> > we allocate the ForwardClass instance C, we make it as big as a class
> > object can ever get.  (Mark Shannon assures me this is simply "heap
> > type", and he knows far more about CPython internals than I ever will.)




This proposal will indeed surpass almost all concerns I raised earlier, if
not all.
It is perfectly legal to have a custom metaclass not passing "**kwargs" to
type.__new__, and
I think most classes don't do it: these in general do not expect a
"**kwargs" in general and
will simply not run the first time the code is called, and could be updated
at that point. Besides,
there is no problem in keeping this compatible for "pre" and "pos' this
PEP.


I had thought of that possibility before typing my other answers, and the
major
problem of "inplace modifying' is that one can't know for sure the final
size
of the class due to "__slots__". Over allocating a couple hundred bytes
could make
for reasonable slots, but it could simply raise a runtime exception if the
final call
would require more slots than this maximum size - so, I don't think this is
a blocking concern.


As for

> What could go wrong?  My biggest question so far: is there such a thing as
> a metaclass written in C, besides type itself?  Are there metaclasses with
> a __new__ that *doesn't* call super().__new__ or three-argument type?  If
> there are are metaclasses that allocate their own class objects out of raw
> bytes, they'd likely sidestep this entire process.  I suspect this is rare,
> if indeed it has ever been done.  Anyway, that'd break this mechanism, so
> exotic metaclasses like these wouldn't work with "forward-declared
> classes".  But at least they needn't fail silently.  We just need to add a
> guard after the call to metaclass.__new__: if we passed in "__forward__=C"
> into metaclass.__new__, and metaclass.__new__ didn't return C, we raise an
> exception.


That. There are some metaclasses. I did not check, but I do suspect even
some of the builtin-types like "list"  and "tuple" do
bypass "type.__new__" (they fail when used with multiple inheritance along
with ABCs, in that they do not check
for abstractmethods). This is fixable. Third party "raw' metaclasses that
re-do the object structure could simply
runtime err until, _and if ever desired_, rewritten to support this feature
as you put it.

Even for metaclasses in pure Python, sometimes they won't resolve to an
instance of the class itself
(think of the behavior seen in pathlib.Path which acts as a factory to a
subclass)- I see no
problem in these just not supporting this feature as well.


==

With this in mind, the major concerns are those put by Carl Meyer on the
"Part 1" thread,
namely, that this might not be usable for static checking at all -
https://mail.python.org/archives/list/python-dev@python.org/message/NMCS77YFM2V54PUB66AXEFTE4NXFHWPI/

And, of course, my suggestion that the problem this tries to resolve is
already
resolved by the use of typing.Protocol, as far as type-checking is
concerned. Adding a way
for a Protocol to be able to find its registered implementations and
instantiate one
of them  when needed would solve this for "real forward referencing" as
well.

All in all, I still think this complicates things too much for little gain
-
people needing real forward references always could find a way out,
since Python 2 times.

And, while in my earlier e-mails I wrote that I mentioned
PEP 563 could also resolve this, I really was thinking about
PEP 649 - although, I think, actually, any of the 2 could solve
the problem annotation wise. If needed for "real code" instead
of annotations, extending Protocol so that it can find
implementations, could work as well.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/2DILNMWKRO4MZBTDPYHV7K3WCGR2UOHY/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Starting a new thread

2022-05-10 Thread Joao S. O. Bueno
On Tue, May 10, 2022 at 1:20 PM Paul Moore  wrote:

> On Tue, 10 May 2022 at 16:31, Barney Stratford
>  wrote:
> >
> > Hello all.
> >
> > It occurs to me that creating threads in Python is more awkward than it
> needs to be. Every time I want to start a new thread, I end up writing the
> same thing over and over again:
> >
> > def target(*args, **kwds):
> > ...
> > t = threading.Thread(target = target, args = , kwargs=
> )
> > t.start()
> >
> > This becomes especially repetitive when calling a target function that
> only makes sense when run in a new thread, such as a timer.
> >
> > In my own code, I’ve taken to decorating functions that always run in
> new threads. Then I can call the function using the usual function call
> syntax, and have the new thread returned to me. With the decorator, the
> code reads instead:
> >
> > @threaded
> > def target(*args, **kwds):
> > …
> > t = target(*args, **kwds)
> >
> > This has a couple of advantages. I don’t have to import the threading
> module all over my code. I can use the neater syntax of function calls. The
> function’s definition makes it clear it’s returning a new thread since it’s
> decorated. It gets the plumbing out of the way so I can concentrate more on
> what my code does and less in how it does it.
> >
> > It feels like the right place for this decorator is the standard
> library, so I’ve created PR #91878 for it. @rhettinger suggests that this
> is a bit premature, and that we should discuss it here first. Thoughts?
>
> I like this. I'd probably use it if it existed. Your example isn't
> particularly compelling, though - calling the function "target" makes
> sense when it's the target of the thread, but not so much when it's
> the thread itself. Could you give a motivating example based on real
> code, rather than just the "this is what the syntax would look like"
> as you did above? Ideally showing what it would look like with and
> without the decorator?
>
> Things I *think* i get, but I'd like to see clearly in an example, include:
>
> 1. Does t = target(...) start the thread? I think it does.
> 2. Is it possible to create daemon threads? @threaded(daemon=True)
> seems plausible. I suspect your PR doesn't have this, but it wouldn't
> be difficult to add. But I don't actually know if it's worth adding,
> TBH.
> 3. Can you create multiple threads for the same function? I assume t1,
> t2, t3 = target(arg1), target(arg2), target(arg3) would work.
>
> I'm probably being dense here - I'm pretty sure your proposal actually
> is as simple as it looks (which is a good thing!) and I'm just
> over-complicating things in my head.
>
> Things that come to mind that should be considered here:
1) not every two liner function should be added to the stdlib
and, on the other hand,
2) asyncio features `loop.run_in_executor`
which does essentially the same, with more care for what happens
in "real world" code, but is only usable in async code.

all in all it can be useful for quick and dirty code - and maybe
something more elaborate allowing control on whether to create
daemon threads, or maybe something that will deal with
concurrent.future.executors
as well, and allow access to the function call results

All in all, I find it a nice snippet, but one that is not aligned with
the trend Python has been taking over the last years,
facilitating the writing of "quick and dirty" scripts in contrast
with application code that will take care of all possible corner-cases.

As a good example of what I am talking about, we've seen the contrary
 movement take place, long ago, when
"os.popen" was superseded by "subprocess.*": I think up to today people
had not catched up with the far more complicated API of the latter.

All in all, I'd eventually use this "@threaded" if it was there.



> Paul
>
>js
  -><-
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FWSH6ZXIQQ3S5JOTUEXDZULBRDFIJSEB/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Method __func__ objects are unpicklable

2022-06-10 Thread Joao S. O. Bueno
This is not just about the content of the name attributes: ;bound methods
do contain a reference to the specific instance
they are bound too - which is not retrievable (or maybe is through some
dunder attribute) - this instance has to be pickled, transported
and its reference updated on unpickling.

On Fri, Jun 10, 2022 at 9:00 AM haael  wrote:

>
>
> During some sophisticated pickling I noticed that method `__func__`
> objects are unpicklable, because they share the name with the bound
> method object itself.
>
>
> ```
> from pickle import dumps
>
> class A:
>  @classmethod
>  def b(cls):
>  pass
>
> print(A.b) # >
> print(A.b.__func__) # 
>
> dumps(A.b) # works
> dumps(A.b.__func__) # breaks
> # >Traceback (most recent call last):
> # >  File "", line 1, in 
> # >_pickle.PicklingError: Can't pickle :
> # >it's not the same object as __main__.A.b
> ```
>
>
> The last call compains that global symbol "A.b" is not the same object
> as `A.b.__func__`.
>
> Everything would work if the `__func__` objects had the suffix
> ".__func__" in their qualname.
>
> Actually setting the qualname of the `__func__` object makes it
> picklable, but then the bound method object is unpicklable, as it
> inherits the name from the `__func__`. It would be good if they were
> separate.
>
> This is an attempt at emulating the desired behavior:
>
>
> ```
> from pickle import dumps
>
> class A:
>  pass
>
> def c(cls):
>  pass
>
> A.c = lambda: c(A)
> A.c.__qualname__ = "A.c"
> A.c.__name__ = "c"
> A.c.__self__ = A
> A.c.__func__ = c
> A.c.__func__.__qualname__ = "A.c.__func__"
>
> print(A.c) # 
> print(A.c.__func__) # 
>
> dumps(A.c) # works
> dumps(A.c.__func__) # works
> ```
>
>
> Can we make the `__func__` objects picklable this way?
>
>
> haael
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/N2J6MVLURTBAB5PJLJG3LO6U4PTPJMU2/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TZ4DCYPHB2B7U7HOMQG2C4AYVKS3KONI/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Feature Suggestion: "repeat" statement in loops

2023-01-26 Thread Joao S. O. Bueno
I don't think this will fly - if not for any other reason, it is a very
rare pattern
to take place alongside such important flow-control statements as
continue and break

But for your convenience, here is a small wrapper that, along with the
walrus operator, could be used when you need that functionality:

```
class Repeatable:
def __init__(self, it):
self.it = it
self.repeat_last = False
self.last_item = None
def repeat(self):
self.repeat_last = True
def __iter__(self):
for item in self.it:
while self.repeat_last:
self.repeat_last = False
yield self.last_item
self.last_item = item
yield item


test = 1
for x in (rx:=Repeatable(range(3))):
print(x)
if x == test:
test = -1
rx.repeat()
```

On Thu, Jan 26, 2023 at 4:41 PM Thomas Ratzke 
wrote:

> Hi all,
>
> i would like to suggest the following Python feature. It naturally
> happens that one want's to repeat the current iteration of a for loop
> for example after an error happened. For this purpose, I usually set a
> flag and put a while loop inside my for loop. A simple "repeat"
> statement just like "continue" or "break" would make the code much more
> readable.
>
>
> This is my solution at the moment with A being checked:
>
> for _ in range(n):
>  flag = True
>  while flag:
>  ...
>  if A:
>  flag = False # go to next iteration
>
>
> I would suggest the repeat statement in the following sense
>
> for _ in range(n):
>  ...
>  if not A:
>  repeat # repeat current iteration
>
> Notice the "not" in the if clause. I am really looking forwars to hear
> your opinions.
>
> Best regards
> Thomas
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/LNER4MH6IT6HBFKFVTUOJ225PTCZSRRC/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WWEJQD7IIPNC4FUSPHLXEH7SVN6EVK6H/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 572 TargetScopeError

2019-08-09 Thread Joao S. O. Bueno
I just read your e-mail (before reading any follow up here), fired up
Python 3.8 and typed in
what I thought would be an ambiguous or confuse case, withut checking the
PEP.

the result:
```
Python 3.8.0b3+ (heads/3.8:ef0b81927a, Aug  6 2019, 20:30:57)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.7.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: class A:
  ...: b = 0
  ...: any((b:= i, 0)[1] for i in range(10))

 File "", line 3
   any((b:= i, 0)[1] for i in range(10))
   ^
TargetScopeError: named expression within a comprehension cannot be used in
a class body
```

So, while the name "TargetScopeError" can sound confusing,
 I think the extended error message could not be more
clear and unambiguous. It seems just fine as it is.



On Thu, 8 Aug 2019 at 14:02, Barry Warsaw  wrote:

> bpo-37757: https://bugs.python.org/issue37757
>
> This issue describes some corner cases in PEP 572 (assignment expressions)
> syntax that haven’t been implemented yet.  The PEP currently says:
>
> "The two invalid cases listed above raise TargetScopeError, a new subclass
> of SyntaxError (with the same signature).”
>
> The PEP doesn’t really go into the rationale for why a new exception is
> being defined, and in the issue I’ve argued that we should just raise
> SyntaxError in those cases.  To me, “TargetScopeError” is pretty obscure
> and doesn’t give users an obvious clue as to what’s going wrong, without
> searching the interwebs.
>
> Nick argues (apologies if I’m misrepresenting you!):
>
> "I believe our main motivation for separating it out was the fact that
> even though TargetScopeError is a compile-time error, the affected code is
> syntactically fine - there are just issues with unambiguously inferring the
> intended read/write location for the affected target names. (Subclassing
> SyntaxError is then a pragmatic concession to the fact that "SyntaxError"
> also de facto means "CompilationError”)”
>
> Serhiy points out that we have IndentationError and TabError subclasses of
> SyntaxError, but those feel different to me because the exception names
> themselves are clear and descriptive, and lead to obvious actionable
> remedies.
>
> Guido then suggests we take the discussion here, thus this email.
>
> It would be a very minor update to the PEP, but I think it’s useful to
> resolve before the last push for PEP 572 implementation gets completed.
>
> Rather than just a vote, if you have a rationale for one over the other,
> I’d love to hear it.  Feel free to weigh in here or on the issue.
>
> Cheers,
> -Barry
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/FXVSYCTQOTT7JCFACKPGPXKULBCGEPQY/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VPFUBLP5KZTDZYBHLF6HFDB6IC3BZB2D/


[Python-Dev] Re: PEP proposal to limit various aspects of a Python program to one million.

2019-12-04 Thread Joao S. O. Bueno
* The number of classes in a running interpreter.
* The number of live coroutines in a running interpreter.

These two can (and coroutines actually are always) dynamically generated -
and it is not hard to imagine
scenarios were 1 million for these would easily be beaten.

I don't know the data structures needed for those, but it would be much
saner to keep
both limited to 2**32 (due to reasons on artificial limiting the word
length as put by
others), or at least a much higher count.



On Tue, 3 Dec 2019 at 13:22, Mark Shannon  wrote:

> Hi Everyone,
>
> I am proposing a new PEP, still in draft form, to impose a limit of one
> million on various aspects of Python programs, such as the lines of code
> per module.
>
> Any thoughts or feedback?
>
> The PEP:
> https://github.com/markshannon/peps/blob/one-million/pep-100.rst
>
> Cheers,
> Mark.
>
>
> Full text
> *
>
> PEP: 100
> Title: The one million limit
> Author: Mark Shannon 
> Status: Active
> Type: Enhancement
> Content-Type: text/x-rst
> Created: 03-Dec-2019
> Post-History:
>
>
>
> Abstract
> 
> This PR proposes a limit of one million (1 000 000) for various aspects
> of Python code and its implementation.
>
> The Python language does not specify limits for many of its features.
> Not having any limit to these values seems to enhance programmer freedom,
> at least superficially, but in practice the CPython VM and other Python
> virtual
> machines have implicit limits or are forced to assume that the limits are
> astronomical, which is expensive.
>
> This PR lists a number of features which are to have a limit of one
> million.
> If a language feature is not listed but appears unlimited and must be
> finite,
> for physical reasons if no other, then a limit of one million should be
> assumed.
>
>
> Motivation
> ==
>
> There are many values that need to be represented in a virtual machine.
> If no limit is specified for these values, then the representation must
> either be inefficient or vulnerable to overflow.
> The CPython virtual machine represents values like line numbers,
> stack offsets and instruction offsets by 32 bit values. This is
> inefficient, and potentially unsafe.
>
> It is inefficient as actual values rarely need more than a dozen or so
> bits to represent them.
>
> It is unsafe as malicious or poorly generated code could cause values to
> exceed 2\ :sup:`32`.
>
> For example, line numbers are represented by 32 bit values internally.
> This is inefficient, given that modules almost never exceed a few
> thousand lines.
> Despite being inefficent, is is still vulnerable to overflow as
> it is easy for an attacker to created a module with billions of newline
> characters.
>
> Memory access is usually a limiting factor in the performance of modern
> CPUs.
> Better packing of data structures enhances locality and reduces memory
> bandwith,
> at a modest increase in ALU usage (for shifting and masking).
> Being able to safely store important values in 20 bits would allow
> memory savings
> in several data structures including, but not limited to:
>
> * Frame objects
> * Object headers
> * Code objects
>
> There is also the potential for a more efficient instruction format,
> speeding up interpreter dispatch.
>
> Rationale
> =
>
> Imposing a limit on values such as lines of code in a module, and the
> number of local variables,
> has significant advantages for ease of implementation and efficiency of
> virtual machines.
> If the limit is sufficiently large, there is no adverse effect on users
> of the language.
>
> By selecting a fixed but large limit for these values,
> it is possible to have both safety and efficiency whilst causing no
> inconvience to human programmers
> and only very rare problems for code generators.
>
> One million
> ---
>
> The Java Virtual Machine (JVM) [1]_ specifies a limit of 2\ :sup:`16`-1
> (65535) for many program
> elements similar to those covered here.
> This limit enables limited values to fit in 16 bits, which is a very
> efficient machine representation.
> However, this limit is quite easily exceeded in practice by code
> generators and
> the author is aware of existing Python code that already exceeds 2\
> :sup:`16` lines of code.
>
> A limit of one million fits into 20 bits which, although not as
> convenient for machine representation,
> is still reasonably compact. Three signed valuses in the range -1000_000
> to +1000_000 can fit into a 64 bit word.
> A limit of one million is small enough for efficiency advantages (only
> 20 bits),
> but large enough not to impact users (no one has ever written a module
> of one million lines).
>
> The value "one million" is very easy to remember.
>
> Isn't this "640K ought to be enough for anybody" again?
> ---
>
> The infamous 640K memory limit was a limit on machine usable resources.
> The proposed one million limit is a limit on human generated code.
>
> While it is 

[Python-Dev] Re: PEP proposal to limit various aspects of a Python program to one million.

2019-12-05 Thread Joao S. O. Bueno
>
> Assuming a code base of 50M loc, *and* that all the code would be loaded
> into a single application (I sincerely hope that isn't the case) *and*
> that each class is only 100 lines, even then there would only be 500,000
> classes.
> If a single application has 500k classes, I don't think that a limit of
> 1M classes would be its biggest problem :)


It is more like 1 million calls to `type` adding some linear combination of
attributes
to a base class.

Think of a persistently running server that would create dynamic named
tuples lazily.
(I am working on code that does that, but with currently 5-6 attributes -
that gives me up to 64 classes,
but if I had 20 attributes this code would hit that limit - (if one would
use the lib in a persistent server, that is :-)  )

Anyway, not happening soon - I am just writting to say that one million
classes does not mean 1 million hard-codeed 100 LoC classes,
rather, it is 1 million calls to "namedtuple".

On Thu, 5 Dec 2019 at 11:30, Mark Shannon  wrote:

> Hi Guido,
>
> On 04/12/2019 3:51 pm, Guido van Rossum wrote:
> > I am overwhelmed by this thread (and a few other things in real life)
> > but here are some thoughts.
> >
> > 1. It seems the PEP doesn't sufficiently show that there is a problem to
> > be solved. There are claims of inefficiency but these aren't
> > substantiated and I kind of doubt that e.g. representing line numbers in
> > 32 bits rather than 20 bits is a problem.
>
> Fundamentally this is not about the immediate performance gains, but
> about the potential gains from not having to support huge, vaguely
> defined limits that are never needed in practice.
>
> Regarding line numbers,
> decoding the line number table for exception tracebacks, profiling and
> debugging is expensive and the cost is linear in the size of the code
> object. So, the performance benefit would be largest for the code that
> is nearest to the limits.
>
> >
> > 2. I have handled complaints in the past about existing (accidental)
> > limits that caused problems for generated code. People occasionally
> > generate *really* wacky code (IIRC the most recent case was a team that
> > was generating Python code from machine learning models they had
> > developed using other software) and as long as it works I don't want to
> > limit such applications.
>
> The key word here is "occasionally". How much do we want to increase the
> costs of every Python user for the very rare code generator that might
> bump into a limit?
>
> >
> > 3. Is it easy to work around a limit? Even if it is, it may be a huge
> > pain. I've heard of a limit of 65,000 methods in Java on Android, and my
> > understanding was that it was actually a huge pain for both the
> > toolchain maintainers and app developers (IIRC the toolchain had special
> > tricks to work around it, but those required app developers to change
> > their workflow). Yes, 65,000 is a lot smaller than a million, but in a
> > different context the same concern applies.
>
> 64k *methods* is much, much less than 1M *classes*. At 6 methods per
> class, it is 100 times less.
>
> The largest Python code bases, that I am aware of, are at JP Morgan,
> with something like 36M LOC and Bank of America with a similar number.
>
> Assuming a code base of 50M loc, *and* that all the code would be loaded
> into a single application (I sincerely hope that isn't the case) *and*
> that each class is only 100 lines, even then there would only be 500,000
> classes.
> If a single application has 500k classes, I don't think that a limit of
> 1M classes would be its biggest problem :)
>
> >
> > 4. What does Python currently do if you approach or exceed one of these
> > limits? I tried a simple experiment, eval(str(list(range(200,
> > and this completes in a few seconds, even though the source code is a
> > single 16 Mbyte-long line.
>
> You can have lines as long as you like :)
>
> >
> > 5. On the other hand, the current parser cannot handle more than 100
> > nested parentheses, and I've not heard complaints about this. I suspect
> > the number of nested indent levels is similarly constrained by the
> > parser. The default function call recursion limit is set to 1000 and
> > bumping it significantly risks segfaults. So clearly some limits exist
> > and are apparently acceptable.
> >
> > 6. In Linux and other UNIX-y systems, there are many per-process or
> > per-user limits, and they can be tuned -- the user (using sudo) can
> > change many of those limits, the sysadmin can change the defaults within
> > some range, and sometimes the kernel can be recompiled with different
> > absolute limits (not an option for most users or even sysadmins). These
> > limits are also quite varied -- the maximum number of open file
> > descriptors is different than the maximum pipe buffer size. This is of
> > course as it should be -- the limits exist to protect the OS and other
> > users/processes from runaway code and intentional attacks on resources.
> > (And yet, fork b

[Python-Dev] Re: PEP proposal to limit various aspects of a Python program to one million.

2019-12-06 Thread Joao S. O. Bueno
* The number of live coroutines in a running interpreter: Implicitly
limited by operating system limits until at least 3.11.

DOes the O.S. limit anything on a coroutine?
What for? As far as I know it is a minimal Python-only object, unless you
have each co-routine holding a reference
to a TCP socket - but that has nothing to do with Python's limits itself: a
couroutine by itself is a small Python object
with no external resources referenced - unlike a thread, and code with tens
of thousands of coroutines can run perfectly
without  a single glitch.

Of all limits mentioned in the PEP, this is the one I find no reason to
exist, and that could eventually lead to needles breaking of otherwise
perfectly harmless code.
(The limit on the number of classes also is strange for me, as I've written
in other mails)



On Fri, 6 Dec 2019 at 13:39, Michael  wrote:

> On 03/12/2019 17:15, Mark Shannon wrote:
> > Hi Everyone,
> >
> > I am proposing a new PEP, still in draft form, to impose a limit of
> > one million on various aspects of Python programs, such as the lines
> > of code per module.
> >
> > Any thoughts or feedback?
> >
> > The PEP:
> > https://github.com/markshannon/peps/blob/one-million/pep-100.rst
> >
> > Cheers,
> > Mark.
>
> Shortened the mail - as I want my comment to be short. There are many
> longish ones, and have not gotten through them all.
>
> One guiding principle I learned from a professor (forgot his name sadly).
>
> A program has exactly - zero (0) of something, one (1) of something, or
> infinite. The moment it gets set to X, the case for X+1 appears.
>
> Since we are not talking about zero, or one - I guess my comment is make
> sure it can be used to infinity.
>
> Regards,
>
> Michael
>
> p.s. If this has already been suggested - my apologies for any noise.
>
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/IDACDRYRQDYUB3YZFANONLKZFR6LPOE7/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZSTUKNVN5546YHEX75UK5ROOW3LUMYPB/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Please be more precise when commenting on PEP 611.

2019-12-09 Thread Joao S. O. Bueno
Also,
I've pointed at two of those limits that worry me some - namely
number of classes and number of co-routines, and had not
seen so far any feedback even whether they actually make sense.

A simple data analysis tasks that create a co-routine per row, and submit
those
for workers with more than 1 million rows is something that  just works
today, and is not even
a burden in a desktop machine would hit such limits.

Is there an easy way to locate the data-structures that would be changed on
cpython
that would need to be changed to limit classes and co-routines? I'd like to
have at
least a little more concrete  idea of what could possibly be optimized if
they were capped.


  js
 -><-

On Mon, 9 Dec 2019 at 11:22, Chris Angelico  wrote:

> On Tue, Dec 10, 2019 at 1:09 AM Mark Shannon  wrote:
> > Bear in mind that the costs of higher limits are paid by everyone, but
> > the benefits are gained by few.
>
> Can we get some stats on what the costs of higher limits (or having no
> limit at all) is? Or, putting it the other way: Since CPython
> currently does not enforce limits, what are the benefits of placing
> those limits? Merely having a limit doesn't in itself give a benefit
> (and is a (minor) cost); it would help the discussion if we knew
> exactly WHAT the costs of the higher limits were.
>
> ChrisA
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/4IKBEMNGC5DZXOAR555ZUGNJGWSFV3QI/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/2AVYQHPY3VSW6O7OFAMD2PKSXBS2YQH4/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Adding a "call_once" decorator to functools

2020-04-30 Thread Joao S. O. Bueno
On Thu, 30 Apr 2020 at 00:37, Raymond Hettinger
 wrote:
>
>
>
> > On Apr 29, 2020, at 4:20 PM, Antoine Pitrou  wrote:
> >
> > On Wed, 29 Apr 2020 12:01:24 -0700
> > Raymond Hettinger  wrote:
> >>
> Also, if you know of a real world use case, what solution is currently being 
> used.  I'm not sure what alternative call_once() is competing against.

Of course this is meant to be something simple - so there are no "real
world use cases" that are "wow, it could not have
been done without it". I was one of the first to reply to this on
"python-ideas", as I often need the pattern, but seldon
worrying about rentrancy, or parallel calling. Most of the uses are
just that: initalize a resource lazily, and just
"lru_cache" could work. My first thought was for something more
light-weight than lru_cache (and a friendlier
name).

So, one of the points I'd likely have used this is here:

https://github.com/jsbueno/terminedia/blob/d97976fb11ac54b527db4183497730883ba71515/terminedia/unicode.py#L30

> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/Y2MUKYDCV53PBWRRBU4ZAKB5XED4X4HX/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DJMIZ7Q3ZD5IKOOB73SEZNFVEAN34RMW/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: type() does not call __prepare__?

2020-06-01 Thread Joao S. O. Bueno
But on calling `type` in this way, you are passing the namespace as a
ready object, as the
3rdy parameter - what would `__prepare__` even do, besides print it's
been called?

For sometime (maybe Python 3.3, I forgot), some helper
callables where added to the `types` module to allow
one to have more freedom in imperatively created classes:

 python

In [20]: types.prepare_class?
Signature: types.prepare_class(name, bases=(), kwds=None)
Docstring:
Call the __prepare__ method of the appropriate metaclass.

Returns (metaclass, namespace, kwds) as a 3-tuple

*metaclass* is the appropriate metaclass
*namespace* is the prepared class namespace
*kwds* is an updated copy of the passed in kwds argument with any
'metaclass' entry removed. If no kwds argument is passed in, this will
be an empty dict.
File:  ~/projetos/terminedia/env/lib64/python3.7/types.py
Type:  function

In [21]: types.new_class?
Signature: types.new_class(name, bases=(), kwds=None, exec_body=None)
Docstring: Create a class object dynamically using the appropriate metaclass.
File:  ~/projetos/terminedia/env/lib64/python3.7/types.py
Type:  function

In [22]: types.resolve_bases?
Signature: types.resolve_bases(bases)
Docstring: Resolve MRO entries dynamically as specified by PEP 560.
File:  ~/projetos/terminedia/env/lib64/python3.7/types.py
Type:  function
```

On Mon, 1 Jun 2020 at 16:28, Ethan Furman  wrote:
>
>  From stackoverflow [1]
>
># metaprepare.py
>class Meta1(type):
>@classmethod
>def __prepare__(mcs, name, bases):
>print('call prepare')
>return {}
>def __new__(mcs, name, bases, parameters):
>return super().__new__(mcs, name, bases, parameters)
>
>class A(metaclass=Meta1):
>pass
>
>type('C', (A, ), {})
>
> output is:
>
>call prepare
>
> (just the once, not twice)
>
> The behavior of `type()` not calling `__prepare__()` has been constant since 
> 3.3.
>
> Is it a bug?
>
>
> --
> ~Ethan~
>
>
> [1] https://stackoverflow.com/q/62128254/208880
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/CQTD7WFOIDBF5PSD77AALBTWJQ67UPM5/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/IPBWREEI6JYGWROTSXGHBWLG53Q4A23A/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

2020-06-24 Thread Joao S. O. Bueno
On Wed, 24 Jun 2020 at 16:40, Guido van Rossum  wrote:

> Everyone,
>
> If you've commented and you're worried you haven't been heard, please add
> your issue *concisely* to this new thread. Note that the following issues
> are already open and will be responded to separately; please don't bother
> commenting on these until we've done so:
>
> - Alternative spellings for '|'
> - Whether to add an 'else' clause (and how to indent it)
> - A different token for wildcards instead of '_'
> - What to do about the footgun of 'case foo' vs. 'case .foo'
>

I'd like also to see considerations about the issue of an alternative
spelling that would
not resemble a class instantiation, brought first by Antoine Pitrou:
```

case Point with (x, y):
 print(f"Got a point with x={x}, y={y}")
 ```

And somewhere on the other thread, someone pointed
the possibility of all assignments in a case be well
delimited, even with angle parentheses - (yes, that
addresses the "foot gun" again, but it is a step beyond
dot or not dot in instant-readability:

```
case Point with (, ):
 print(f"Got a point with x={x}, y={y}")
```

(AFAIC, the "dot" thing falls in the category of speckles on Tim's monitor)

-- 
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/STJSSAETMTUY7FK5AE53IM73Z2WORNYN/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GOA2EZUELOQ2J6KO6ZHSNTGK3ERRPMGY/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Function suggestion: itertools.one()

2020-07-28 Thread Joao S. O. Bueno
On Tue, 28 Jul 2020 at 15:16, Brett Cannon  wrote:

> For ideas like this it is best to discuss them on python-ideas.
>
> I'll also mention that this idea has been brought up at least twice
> before: search for threads about itertools and single() or first() (if I
> remember correctly).
>
I think "first" even passed "general approval'   last time around (about 1
month ago) -  but I can't recall if someone
took the responsibility of carrying that forward.

>
> On Mon, Jul 27, 2020 at 12:07 PM Noam Yorav-Raphael 
> wrote:
>
>> Hi,
>>
>> There's a simple function that I use many times, and I think may be a
>> good fit to be added to itertools. A function that gets an iterator, and if
>> it has exactly one element returns it, and otherwise raises an exception.
>> This is very useful for cases where I do some sort of query that I expect
>> to get exactly one result, and I want an exception to be raised if I'm
>> wrong. For example:
>>
>> jack = one(p for p in people if p.id == '1234')
>>
>> sqlalchemy already has such a function for queries:
>> https://docs.sqlalchemy.org/en/13/orm/query.html#sqlalchemy.orm.query.Query.one
>>
>> This is my implementation:
>>
>> def one(iterable):
>> it = iter(iterable)
>> try:
>> r = next(it)
>> except StopIteration:
>> raise ValueError("Iterator is empty")
>> try:
>> next(it)
>> except StopIteration:
>> return r
>> else:
>> raise ValueError("Iterator has more than one item")
>>
>> What do you think?
>>
>> Thanks,
>> Noam
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/D52MPKLIN4VEXBOCKVMTWAK66MAOEINY/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/RO5PFRG4PCHFQGQPEJIXP5TGUF3KSZYO/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/257F5YVGORDSDKMTGGX7FAQKHSNHA32I/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

2020-07-29 Thread Joao S. O. Bueno
On Fri, 17 Jul 2020 at 12:28, Gustavo Carneiro  wrote:

>
>
> On Fri, 17 Jul 2020 at 12:26,  wrote:
>
>> Hello everyone,
>> (...)
>> But... looking at the examples, it wasn't very obvious that some
>> variables were catching variables and some others were matching ones.
>> I then read in details some rules about how to discover what is a
>> captured variable. But I'm not sure everybody will do this...
>>
>> Zen of Python tells us that "explicit is better than implicit". I know
>> this is not a rule written in the stone, but I think here, it applies
>> very well.
>>
>>
I Also  dislike the idea of undotted names being assigned, with not extra
visual clues,
and the scenario described by Emmanuel, in the other e-mail about
people changing variables when they think they are making a match
(essentially introducing the _same_ problem that `if (SPAM = 0):` had in C
which Python used to justify assignment not being an expression for over
20 years).

So, in adding to the bikeshed color possibilities, alongside
the "x=, y=" in this first e-mail or the "_ as x, _ as y" from Gustavo,
I present the possibility of making the Walrus mandatory for capture.
Maybe it is a bit "too much typing" - (Walrus will require 5-6 keystrokes
with the surrounding spaces), but I think the final look can be pleasantly
intuitive:

match my_point:
case (x := _, y := _) | Point2d(x := _, y := _):
   return Point3d(x, y, 0)




> Guido said :
>> > We’re really looking
>> > for a solution that tells you when you’re looking at an individual
>> > case which variables are captured and which are used for
>> > load-and-compare.
>> >
>> > Marking up the capture variables with some sigil (e.g. $x or
>> > x?)
>> > or other markup (e.g. backticks or ) makes this common case ugly
>> > and inconsistent: it’s unpleasant to see for example
>> >
>> > case %x, %y:
>> > print(x, y)
>>
>> Guido talk about a "sigil", which seems to be a meaningless mark only
>> here to help the parser understand what the dev was writing.
>>
>> I propose that this "sigil" be the affectation mark : "=". Look :
>>
>> z = 42
>> match pt:
>> case x=, y=, z:
>> print(x, y, "z == 42")
>>
> (...)
 Gustavo Carneiro  wrote:

> I kind of agree it is nicer to be more explicit.  But somehow x= looks
> ugly. It occurred to me (and, again, apologies if already been mentioned),
> we might use the `as` keyword here.
>
> The example above would become:
>
> def make_point_3d(pt):
> match pt:
> case (as x, as y):
> return Point3d(x, y, 0)
> case (as x, as y, as z):
> return Point3d(x, y, z)
> case Point2d(as x, as y):
> return Point3d(x, y, 0)
> case Point3d(_, _, _):
> return pt
> case _:
> raise TypeError("not a point we support")
>
> If having "as x" as a standalone expression without anything to the left
> of "as" causes confusion, we could instead mandate the use of _ thus:
>
> case (_ as x, _ as y):
> return Point3d(x, y, 0)
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/EZGTHXOYTHRQ6JCEP7B26IA5RVGHEZAC/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

2020-07-29 Thread Joao S. O. Bueno
On Sat, 18 Jul 2020 at 14:12, Steven D'Aprano  wrote:

> On Sat, Jul 18, 2020 at 09:25:45AM -,
> emmanuel.coir...@caissedesdepots.fr wrote:
>
> > This approach, for me, seems to come from functionnal languages where
> > pattern matching is a thing. The proposed "match" clause tends to
> > mimic this approach, and it can be a good thing. But the Python's
> > function definition has not been inspired by functionnal programming
> > from the ground, and I think it would be an error to reason this way,
> > because people not used to pattern matching in functionnal programming
> > won't understand anything (imagine that comprehension lists are a big
> > thing for many learners).
>
> It is true that beginners sometimes struggle a bit to grok comprehension
> syntax. I know I did.
>
> And yet, despite that, comprehensions have turned out to be one of the
> most powerful and popular features of Python, sometimes *too* popular.
> It is sometimes hard to convince both beginners and even experienced
> devs that comprehensions are not the only tool in their toolbox, and not
> every problem is a nail.
>
> You say: "people not used to pattern matching in functionnal programming
> won't understand anything" but people using Haskell weren't born knowing
> the language. They had to learn it.
>
> It's been sometimes said that functional programmers are smarter, elite
> programmers a level above the average OOP or procedural programmer, but
> that's mostly said by functional programmers :-) and I'm not entirely
> sure that its true. In any case, I don't think that any (actual or
> imaginary) gap between the ability of the average Haskell programmer and
> the average Python programmer is so great that we should dismiss pattern
> matching as beyond the grasp of Python coders.
>
> In any case, functional languages like Haskell, F# and ML are not the
> only languages with pattern matching. Non-FP languages like C#, Swift,
> Rust and Scala have it, and even Java has an extension providing pattern
> matching:
>
>
You do a nice job arguing that matching is a nice feature to have -
and I guess we are past this point.

But I don't see one thing in the above characters pointing that
using an undifferentiated name by itself in the match/case construct
will be better than trying to find a way to differentiate it,
and having significant gains in readability and "learnability"

Yes, people aren't born knowing Haskell, but then, one of the strong
points in Python is (or used to be) it _not looking_ like Haskell.

Having a differentiation sign for assignment would also allow
matching against values in variables just work in a very intuitive way,
just like it would have happened with the ".variable_name" in the first
version.

(I've written another e-mail on the thread, but since this scatters around:
my current bikeshed color is to _require_ the walrus op for
assignments like in:  `case (x := _, y := _): ...` )

   js
 -><-


http://tom.loria.fr/wiki/index.php/Main_Page
>
>
> --
> Steven
>
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/2EGPJJXDTAKQVSY75PBE3A7BWCBXAKMZ/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

2020-08-07 Thread Joao S. O. Bueno
Just taking a ride on the thread here,

I made a quick talk on the proposed feature for a local group,
and in the process I refactored a "real world" class I have in a
project, which features a complicated __init__ due having lots
 of different, optional, ways to be initialized.

I can tell I liked what could be done  -
reducing roughly 60 loc packed with "isinstance" calls,
"if/elif" blocks, temporary, intermediate state variables,
into 25 lines including 10 case-clauses that are very
straightforward to read.

Sorry for whoever would like an example differing much of the
"point2d" examples  on the PEP, but the class in question IS geometry
related
and is a Rectangle -


I am not yet testing (neither on the 'normal' if/else version)
_invalid_ arguments - there are a lot of way to pass
conflicting arguments to __init__  - and the if/elif logic
to handle those properly is not in place. The match/case
version for handling these invalid combinations would be
very straight forwad, on the other hand  .

(all said, I think I still miss a way to mark variables that
are assigned in the case clauses, just for the record :-)  )

Enough cheaptalk - links are here:

tests:
https://github.com/jsbueno/terminedia/blob/fa5ac012a7b93a2abe26ff6ca41dbd5f5449cb0b/tests/test_utils.py#L356

Branch comparison for the match/case version:
https://github.com/jsbueno/terminedia/compare/patma

You will notice one "real world" pattern that was needed there: as the case
clauses had
to be aware of values spread across different keyword-parameters, I had to
prepend
a "packing" of all function arguments into a mapping to match against.

If I would not care for the function signature, I could just get "**kwargs"
and match against that.



On Thu, 6 Aug 2020 at 14:09, Brett Cannon  wrote:

>
>
> On Thu, Aug 6, 2020 at 3:46 AM Mark Shannon  wrote:
>
>> Hi Barry,
>>
>> How long do we have to present objections to PEP 622?
>>
>
> We haven't discussed a timeline among ourselves yet (unless it was
> discussed at the last meeting which missed 😁).
>
>
>>
>> I don't feel that the PEP gives adequate prominence to the objections so
>> far raised, and there are more issues I would like to bring up.
>>
>
> I don't think we would want to keep pushing out every time someone has
> more to say as that would mean this would never end. 😉 But I doubt we will
> be making a decision next week, so if you can get any comments in between
> now and the 17th you will probably get it in before the earliest we will
> very optimistically make a decision.
>
> -Brett
>
>
>>
>> Cheers,
>> Mark.
>>
>>
>> On 05/08/2020 5:58 pm, Barry Warsaw wrote:
>> > PEP 622 is already on the SC’s agenda for review.
>> >
>> > -Barry
>> >
>> >> On Aug 5, 2020, at 09:47, Ethan Furman  wrote:
>> >>
>> >> On 7/30/20 8:35 AM, Rob Cliffe via Python-Dev wrote:
>> >>
>> >>> The debate is still going on as to whether "capture" variables should
>> be marked...
>> >> I don't think the PEP authors are debating it any more.  Quite
>> frankly, I wish they would present to the SC and get accepted so we can get
>> Pattern Matching added to 3.10.  :)
>> >>
>> >> --
>> >> ~Ethan~
>> >> ___
>> >> Python-Dev mailing list -- python-dev@python.org
>> >> To unsubscribe send an email to python-dev-le...@python.org
>> >> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> >> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/PGEVEI2W7L32FFCLFOWGFRANMBZHPILQ/
>> >> Code of Conduct: http://python.org/psf/codeofconduct/
>> >
>> >
>> > ___
>> > Python-Dev mailing list -- python-dev@python.org
>> > To unsubscribe send an email to python-dev-le...@python.org
>> > https://mail.python.org/mailman3/lists/python-dev.python.org/
>> > Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/CVYGPSODOHTLEGPRM4EI5GTMR6PHSZLF/
>> > Code of Conduct: http://python.org/psf/codeofconduct/
>> >
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/OSDBFZRZFJVSZ5ZBJ6QFRPWEGL2FJCJZ/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/ESAKYRYV6L6ZMMXO4NTMYOD6OBSOBRQO/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org

Re: [Python-Dev] Did I miss the decision to untabify all of the C code?

2010-05-05 Thread Joao S. O. Bueno
On Wed, May 5, 2010 at 9:59 PM, Eric Smith  wrote:
> Antoine Pitrou wrote:
>>
>> Eric Smith  trueblade.com> writes:
>>>
>>> Last I saw Antoine had written a script that might do what we want, but
>>> hadn't been thoroughly tested. Now I've seen a few checkins for files that
>>> have been run through the script.
>>
>> As far as I'm concerned, it was a case of eating my own dog food: running
>> the
>> script over a couple of files I'm interested in (_ssl.c, _fileio.c). I
>> believe
>> Victor processed posixmodule.c for the same reasons.
>>
>>> What gives? And why do this so close to 2.7? I don't think it will cause
>>> any problems, but it's hard to review commits to ensure they have no changes
>>> when there's a rush of large commits near a release.
>>
>> Well, however soon or late we do this, good luck reviewing multi-thousand
>> line
>> commits to check no mistake sneaked in :)
>
> That's my point. Since it's basically unreviewable, is it smart to do it
> during a beta?

Hello folks -
I don't think these modifications are that "unreviewable": the
generated binaries have to be exactly the same with the untabified
files don't they? So is a matter of stashing the binaries, applying
the patches, rebuild and check to see if the binaries match. Any
possible script defects undetected by this would be only (C code)
indentation, which could be fixed later.

Python 2.7 is in beta, but not applying such a fix now would probably
mean that python 2.x would forever remain with the mixed tabs, since
it would make much less sense for such a change in a minor revision
(although I'd favor it even there).


  js
  -><-



>
> I grant you that it's a largely a mechanized change (except for the "a
> posteriori manual intervention" part), but still.
>
> Eric.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] Fwd: constant/enum type in stdlib

2010-11-24 Thread Joao S. O. Bueno
Hi --

If I may add my 0.02 cents - this sample has a sample implementation
of the proposed features I found most interesting up to now:
1) inherit from int
2) display the constant's name on 'repr'
3) optionally populate a module with the constants
4) Optionally provide a starting value for the enum
5) Optionally provide a mapping with the values


http://pastebin.com/6f1u35qJ

(implementation is in python 2)


Todo here:
6) Make them "read only"
7) Make the base type optional, with "int" as default - but also being able
to create "constants" inheriting from other objects
8) more ideas?

I am willing to play along this sample code as discussion goes on if
there is any feedback.



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


Re: [Python-Dev] Python and the Unicode Character Database

2010-11-28 Thread Joao S. O. Bueno
On Sun, Nov 28, 2010 at 7:04 PM, Antoine Pitrou  wrote:
> On Sun, 28 Nov 2010 15:58:33 -0500
> Alexander Belopolsky  wrote:
>
>> On Sun, Nov 28, 2010 at 3:43 PM, Antoine Pitrou  wrote:
>> ..
>> >> For example,
>> >> I don't think that supporting
>> >>
>> >> >>> float('١٢٣٤.٥٦')
>> >> 1234.56
>> >>
>> >> is more important than to assure users that once their program
>> >> accepted some text as a number, they can assume that the text is
>> >> ASCII.
>> >
>> > Why would they assume the text is ASCII?
>>
>> def deposit(self, amountstr):
>>       self.balance += float(amountstr)
>>       audit_log("Deposited: " + amountstr)
>>
>> Auditor:
>>
>> $ cat numbered-account.log
>> Deposited: ?.??
>
>
> I'm not sure that's how banking applications are written :)
>
+1 for this being bogus  - I see no correlation whatsoever in numbers
inside unicode having to be "ASCII" if we have surpassed all technical
barriers for needing to behave like that.  ASCII is an
oversimplification of human communication needed for computing devices
not complex enough to represent it fully.

Let novice C programmers in English speaking countries deal with the
fact that 1 character is not 1 byte anymore. We are past this point.

  js
  -><-



> Antoine.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Let's get PEP 380 into Python 3.3

2011-02-25 Thread Joao S. O. Bueno
On Fri, Feb 25, 2011 at 8:01 PM, Greg Ewing  wrote:
> From: Guido van Rossum
>
>> (OTOH I am not much enamored with cofunctions, PEP 3152.)
>
> That's okay, I don't like it much myself in its current form.
> I plan to revisit it at some point, but there's no hurry.

I've just gone through PEP 3152 - and the first though that occurred me is
that a decorator is perfectly usable instead of the new proposed
keyword "codef".
(It would need to be able to set special attributes in the function to
indicate its nature)
Besides not adding a new keyword, it would allow for different
(concurrently running? ) types of
co-functions to be created and benefit from the other mechanisms.

But maybe considerations about this should be take place on python-ideas only?



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


Re: [Python-Dev] PyCObject_AsVoidPtr removed from python 3.2 - is this documented?

2011-03-07 Thread Joao S. O. Bueno
On Mon, Mar 7, 2011 at 8:05 PM, Greg Ewing  wrote:
> I'm wondering whether one major release is enough of a
> deprecation period in the current situation. Many people
> haven't started using 3.x in earnest yet, and by the
> time they do, several major releases will have already
> gone by.

That, IMHO, makes it less severe to drop things being marked as
deprecated after just one
major release . This way, most changes can take place before people
migrate to 3.x, and
get all the news at once when they do.

  js
 -><-

>
> --
> Greg
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] GPL'd python code vs Python2.6 linked against OpenSSL

2011-03-09 Thread Joao S. O. Bueno
On Wed, Mar 9, 2011 at 8:20 PM, James Y Knight  wrote:
> It's well known that OpenSSL is incompatible with the GPL. [1] Python (from 
> 2.6) is *always* linked against openssl, instead of waiting for you to 
> "import ssl".
>
> Doesn't this mean it's now impossible (rather, a license violation) to 
> distribute a GPL'd python program (or to use a GPL'd library in your python 
> program)? This seems like a problem...

Hi -


Any libraries commonly avaliable with a CPython instalation can be
considered as "system libraries" for GPL purposes - and so
this would fall in the "system library exception" as described by the FAQ:

http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs

In GPLv2 we have
"""
However, as a special exception, the source code distributed need not
include anything that is normally distributed (in either source or
binary form) with the major components (compiler, kernel, and so on)
of the operating system on which the executable runs, unless that
component itself accompanies the executable.
"""

And in v3:
"""
The “System Libraries” of an executable work include anything, other
than the work as a whole, that (a) is included in the normal form of
packaging a Major Component, but which is not part of that Major
Component, and (b) serves only to enable use of the work with that
Major Component, or to implement a Standard Interface for which an
implementation is available to the public in source code form. A
“Major Component”, in this context, means a major essential component
(kernel, window system, and so on) of the specific operating system
(if any) on which the executable work runs, or a compiler used to
produce the work, or an object code interpreter used to run it.
"""


regards,

   js
  -><-

>
> Thanks to Ulrik Sverdrup  
> (http://lists.debian.org/debian-python/2011/03/msg00082.html) for pointing 
> this out...
>
> James
>
> [1] http://people.gnome.org/~markmc/openssl-and-the-gpl.html
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] GPL'd python code vs Python2.6 linked against OpenSSL

2011-03-09 Thread Joao S. O. Bueno
On Thu, Mar 10, 2011 at 12:49 AM, Westley Martínez  wrote:
> On Wed, 2011-03-09 at 18:20 -0500, James Y Knight wrote:
>> It's well known that OpenSSL is incompatible with the GPL. [1] Python (from 
>> 2.6) is *always* linked against openssl, instead of waiting for you to 
>> "import ssl".
>>
>> Doesn't this mean it's now impossible (rather, a license violation) to 
>> distribute a GPL'd python program (or to use a GPL'd library in your python 
>> program)? This seems like a problem...
>>
>> Thanks to Ulrik Sverdrup  
>> (http://lists.debian.org/debian-python/2011/03/msg00082.html) for pointing 
>> this out...
>>
>> James
>>
>> [1] http://people.gnome.org/~markmc/openssl-and-the-gpl.html
>
> Is it legal to distribute GPL programs that use the Win32 API?

Of course it is -- otherwise no program running on windows could ever
be under the GPL.
You probably are  thinking of Python programs that would specifically
use the win32 extensions --
but implicitly any program, including binary programs, using Windows
will have to use some API from
the OS in order to communicate with the rest of the system and the world.

This "system library" exception could not apply automatically to
Python win32 if its terms where too restrictive or if
it was a component hard to set up, or with a high commercial cost
(neither is the case). But even then, since the licensing
of a Software is ultimately upon its authors, they are always OK to
add special  exceptions to the License file
distributed with the program, stating that this or that library is
exempted from the GPL terms.

What one can't do is to take a work under the GPL, build upon it, and
in this process make use of a library or module
with a license incompatible with the GPL, and redistribute that work
(though, note that even then one is free
to use such a work on his own systems). Because then he'd have to add
that exception to the original
license.

   js
 -><-
That is clear from the examples on the FAQ.


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


Re: [Python-Dev] GPL'd python code vs Python2.6 linked against OpenSSL

2011-03-10 Thread Joao S. O. Bueno
On Thu, Mar 10, 2011 at 2:41 AM, Stephen J. Turnbull  wrote:
> Joao S. O. Bueno writes:
>
>  > Any libraries commonly avaliable with a CPython instalation can be
>  > considered as "system libraries" for GPL purposes - and so
>  > this would fall in the "system library exception" as described by the FAQ:
>
> Note that your interpretation would allow Python to distribute
> arbitrarily licensed libraries and GPL programs to link with them.
> That is surely not the intent of the authors of the GPL, and in the
> past, the FSF has explicitly restricted the interpretation of "system
> library".  Specifically, in
>
>  > "Major Component", in this context, means a major essential component
>  > (kernel, window system, and so on) of the specific operating system
>  > (if any) on which the executable work runs, or a compiler used to
>  > produce the work, or an object code interpreter used to run it.
>
> the word "essential" would refer to running the compiler or the
> operating system or interpreter, not to a component essential to
> running the program but in general optional for using the system.


So tellme how the Python interpreter and the libraries linked to it are not
"essential" to a program made in Python?

I did not refer to distributing Python itself with GPL librareis
linked into it -
you had put it this way.

The original question is whether a Python program can be GPLed, and
the answer is:
it can.

You can see Antonie Pitrou's first answer to question:
" A Python program is not a derivative of the Python interpreter any more
than a C program is a derivative of gcc (or any other compiler)."

The fact is that Python programs need more of environment t run than a
C program,
since besides the system libraries they run oer the Python interpreter and any
libraries it links too: all these are intrinsic in order to the proram to run.
Otherwise no one could ever have a GPLed program written in notoriously
privative language or environments such as Visualbasic, Microsfot's .net,
or even Java using Oracle's Java environment.


> Perhaps this has changed with the advent of GPL v3, but the FSF used
> this interpretation to block the consideration of (old-Qt-licensed) Qt
> as a system library on GNU/Linux systems, even where distributed by
> vendors such as Red Hat.  OTOH, for some reason Motif on Sun and HP
> systems, and Windows and Mac GUIs were considered essential.
>

They where then contradicting their own current FAQs on the GPL.
Anyway, the original author has
always the right to exempt some library his program links to of complying with
the GPL.

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


Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective

2011-03-17 Thread Joao S. O. Bueno
On Thu, Mar 17, 2011 at 8:35 PM, Antoine Pitrou  wrote:
> On Thu, 17 Mar 2011 19:23:30 -0400
> Terry Reedy  wrote:
>> People should retest their stuff with
>> each micro (bugfix) release anyway.
>
> I'm not sure they should. The point of having micro releases is that
> they don't bring any visible change in behaviour - apart from fixing
> bugs, that is.

But IMHO, it would be that, or urging people to use 2to3 from a separate source.
It does not make sense to keep 2to3 frozen while its target moves
forward. Even if
it is decided that things should not be removed, 2to3 should warn of new
deprecations as Python moves into 3.3, 3.4, and beyond.

js
  -><-
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] HTMLParser and HTML5

2011-07-29 Thread Joao S. O. Bueno
On Fri, Jul 29, 2011 at 1:37 AM, Stefan Behnel  wrote:
> Brett Cannon, 28.07.2011 23:49:
>>
>> On Thu, Jul 28, 2011 at 11:25, Matt wrote:
>>>
>>> - What policies are in place for keeping parity with other HTML
>>> parsers (such as those in web browsers)?
>>
>> There aren't any beyond "it would be nice".
>> [...]
>> It's more of an issue of someone caring enough to do the coding work to
>> bring the parser up to spec for HTML5 (or introduce new code to live
>> beside
>> the HTML4 parsing code).
>
> Which, given that html5lib readily exists, would likely be a lot more work
> than anyone who is interested in HTML5 handling would want to invest.
>
> I don't think we need a new HTML5 parsing implementation only to have it in
> the stdlib. That's the old sunny Java way of doing it.
>

I disaagree.
Having proper html parsing out of the box is part of the "batteries
included" thing.
And it is not a matter of "having html 5" - as stated on this thread, fixing it
for html5 will fix it for html that exists in the "real world".

Python _has_ to work with quick 30-50 lines scripts deliverable everywhere, not
just has proper 3rd party libraries that can work as part of a huge
project using buildout.


  js
 -><-

> Stefan
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Maintenance burden of str.swapcase

2011-09-06 Thread Joao S. O. Bueno
On Mon, Sep 5, 2011 at 8:56 AM, Michael Foord  wrote:
> Hey all,
> A while ago there was a discussion of the value of apis like str.swapcase,
> and it was suggested that even though it was acknowledged to be useless the
> effort of deprecating and removing it was thought to be more than the value
> in removing it.
> Earlier this year I was at a pypy sprint helping to work on Python 2.7
> compatibility. The bytearray type has much of the string interface,
> including swapcase… So there was effort to implement this method with the
> correct semantics for pypy. Doubtless the same has been true for IronPython,
> and will also be true for Jython.
> Whilst it is too late for Python 2.x, it *is* (in my opinion) worth removing
> unused and unneeded APIs. Even if the effort to remove them is more than any
> effort saved on the part of users it helps other implementations down the
> road that no longer need to provide these APIs.
> All the best,
> Michael Foord
>

On the other hand,
for any users wanting to use this i n the future, if it is not there,
they'd have to implement the logic for themselves. If it is a "burden"
for someone in a sprint, looking at other implementations, and with
all the unicode knowledge/documentation around, it would be pretty
much undoable in the correct way by a casual user. Removing it would
mean explicitly "batteries removal".

If you get some traction o n that, at least consider moving it to  a
pure python function on the string module.


  js
 -><-

> --
> http://www.voidspace.org.uk/
>
> May you do good and not evil
> May you find forgiveness for yourself and forgive others
> May you share freely, never taking more than you give.
> -- the sqlite blessing http://www.sqlite.org/different.html
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br
>
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Status regarding Old vs. Advanced String Formating

2012-02-26 Thread Joao S. O. Bueno
On 24 February 2012 22:20,  wrote:

> I find the .format syntax too complicated and difficult to learn. It has
> so many bells and whistles, making it more than just a *mini* language.
> So for my own code, I always prefer % formatting for simplicity.
>
> +1



> Regards,
> Martin
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] VS 11 Express is Metro only.

2012-05-25 Thread Joao S. O. Bueno
On 24 May 2012 19:36,   wrote:
>> The free Visual Studio 11 Express for Windows 8 (still in beta) will
>> produce both 32 and 64 bit binaries and allow multiple languages but will
>> only produce Metro apps. For desktop apps, either the paid Visual Studio
>> versions or the free 2010 Express releases are required.
>> https://www.microsoft.com/visualstudio/11/en-us/products/express
>> bottom of page.
>>
>> Will this inhibit someday moving to Visual Studio 11 Professional or would
>> VS2010 Express or VC++2010 Express still work for hacking on Python or
>> making extensions that would work with any VS11-produced binary?
>
>
> I think it's too early to guess what the final release of Visual Studio
> 11 Express will or will not include.

It is better documented here, and seems something to start thinking about:

http://arstechnica.com/information-technology/2012/05/no-cost-desktop-software-development-is-dead-on-windows-8/

>
> Regards,
> Martin
>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)

2012-06-05 Thread Joao S. O. Bueno
On 4 June 2012 21:10, PJ Eby  wrote:

>> > I only use __metaclass__ in 2.x for this because it's the only way for
>> > code
>> > executed in a class body to gain access to the class at creation time.
>> >

PJ,
it maybe just me, but what does this code do that can't be done at the
metaclass' __new__ method?

You might have to rewrite some method-decorators, so that they just
mark a method at class body execution time, and then, whatever the
decorator used to do at this time, would be done at meta's __new__ - I
have this working in some code (and in Python 2 already).

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


Re: [Python-Dev] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)

2012-06-05 Thread Joao S. O. Bueno
On 5 June 2012 09:24, Nick Coghlan  wrote:

>
> PEP written and posted: http://www.python.org/dev/peps/pep-0422/
> More toy examples here:
> https://bitbucket.org/ncoghlan/misc/src/default/pep422.py
>
> Yes, it means requiring the use of a specific metaclass in 3.2 (either
> directly or via inheritance), but monkeypatching an undocumented
> builtin is going to pathological lengths just to avoid requiring that
> people explicitly interoperate with your particular metaclass
> mechanisms.

When reading the PEP, I got the impression that having a
"__decorate__" method on "type", which would perform its thing, would
be not add magic exceptions, would be more explicit and more flexible
than having an extra step to be called between the metaclass execution
and decorator applying.

So, I think that settling for having the decorators applied - as
described in the PEP - in a __decorate__ method of the metaclass would
be nicer and cleaner.

   js
 -><-
>
> Regards,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Should urlencode() sort the query parameters (if they come from a dict)?

2012-08-17 Thread Joao S. O. Bueno
On 17 August 2012 18:52, Chris Angelico  wrote:
> On Sat, Aug 18, 2012 at 5:27 AM, Guido van Rossum  wrote:
>> I just fixed a unittest for some code used at Google that was
>> comparing a url generated by urllib.encode() to a fixed string. The
>> problem was caused by turning on PYTHONHASHSEED=1. Because of this,
>> the code under test would generate a textually different URL each time
>> the test was run, but the intention of the test was just to check that
>> all the query parameters were present and equal to the expected
>> values.
>>
>>
>> query = sorted(query.items())
>
> Hmm. ISTM this is putting priority on the unit test above the
> functionality of actual usage. Although on the other hand, sorting
> parameters on a URL is nothing compared to the cost of network
> traffic, so it's unlikely to be significant.
>

I don't think this behavior is only desirable to unit tests: having
URL's been formed in predictable way  a good thing in any way one
thinks about it.

   js
  -><-

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


Re: [Python-Dev] Should urlencode() sort the query parameters (if they come from a dict)?

2012-08-18 Thread Joao S. O. Bueno
On 18 August 2012 02:23, Stephen J. Turnbull  wrote:
> Joao S. O. Bueno writes:
>
>  > I don't think this behavior is only desirable to unit tests: having
>  > URL's been formed in predictable way  a good thing in any way one
>  > thinks about it.
>
> Especially if you're a hacker.  One more thing you may be able to use
> against careless sites that don't expect the unexpected to occur in
> URLs.
>
> I'm not saying this is a bad thing, but we should remember that the
> whole point of PYTHONHASHSEED is that regularities can be exploited
> for devious and malicious purposes, and reducing regularity makes many
> attacks more difficult.  "*Any* way one thinks about it" is far too
> strong a claim.

Ageeded that "any way one thinks about it" is far too strong a claim -
but I still hold to the point. Maybe "most ways one thinks about it"
:-)  .


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


  1   2   >