[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11
> On Jan 18, 2022, at 11:34 AM, Guido van Rossum wrote: > > > At best it shows that deprecations are complicated no matter how well you > plan them. I remember that "noisy by default" deprecation warnings were > widely despised. > >> On Tue, Jan 18, 2022 at 6:49 AM Antoine Pitrou wrote: >> On Tue, 18 Jan 2022 15:17:41 +0100 >> Victor Stinner wrote: >> > Hi, >> > >> > My colleagues Tomáš Hrnčiar and Miro Hrončok made good progress on >> > updating Python 3.10 to Python 3.11 in Fedora, but some specific >> > Python 3.11 incompatible changes are causing more troubles than >> > others: >> > https://discuss.python.org/t/experience-with-python-3-11-in-fedora/12911 >> > >> > We propose to revert the following 2 changes in Python 3.11 and >> > postpone them in a later Python version, once most projects will be >> > compatible with these changes: >> > >> > * Removal of unittest aliases (bpo-45162): it broke 61 Fedora packages >> > * Removals from configparser module (bpo-45173) - broke 28 Fedora packages >> >> Doesn't this show, once again, that making DeprecationWarning silent by >> default was a mistake? >> > > -- > --Guido van Rossum (python.org/~guido) > Pronouns: he/him (why is my pronoun here?) One thought, what if they were off by default UNLESS you were doing unit tests? That would cut out a lot of the excessive noise issue, but put them in before the programmer when they are developing. Yes, they will get the warnings for dependencies but that lets the programmer apply pressure to fix it or warning they may need to change something if it won’t get fixed.___ 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/UAHZKJNQTMXDORVGX5U5EHKI4HQAV7BN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)
On 11/14/21 2:36 PM, David Mertz, Ph.D. wrote:
On Sun, Nov 14, 2021, 2:14 PM Christopher Barker
It's probably to deal with "é" vs "é", i.e. "\N{LATIN SMALL
LETTER
E}\N{COMBINING ACUTE ACCENT}" vs "\N{LATIN SMALL LETTER E WITH
ACUTE}",
which are different ways of writing the same thing.
Why does someone that wants to use, .e.g. "é" in an identifier
have to be able to represent it two different ways in a code file?
Imagine that two different programmers work with the same code base,
and their text editors or keystrokes enter "é" in different ways.
Or imagine just one programmer doing so on two different
machines/environments.
As an example, I wrote this reply on my Android tablet (with
such-and-such OS version). I have no idea what actual codepoint(s) are
entered when I press and hold the "e" key for a couple seconds to pop
up character variations.
If I wrote it on OSX, I'd probably press "alt-e e" on my US
International key layout. Again, no idea what codepoints actually are
entered. If I did it on Linux, I'd use "ctrl-shift u 00e9". In that
case, I actually know the codepoint.
But would have to look up the actual number to enter them.
Imagine of ALL your source code had to be entered via code-point numbers.
BTW, you should be able to enable 'composing' under Linux too, just like
under OSX with the right input driver loaded.
--
Richard Damon
___
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/N76K3RML5QIFW56BRRVUOW5HGKSJAIVA/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)
On 11/14/21 2:07 PM, Christopher Barker wrote: Why does someone that wants to use, .e.g. "é" in an identifier have to be able to represent it two different ways in a code file? The issue here is that fundamentally, some editors will produce composed characters and some decomposed characters to represent the same actual 'character' These two methods are defined by Unicode to really represent the same 'character', it is just that some defined sequences of combining codepoints just happen to have a composed 'abbreviation' defined also. Having to exactly match the byte sequence says that some people will have a VERY hard time entering usable code if there tools support Unicode, but use the other convention. -- Richard Damon ___ 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/WXGHMDIAY2M77MUMBM4NU7LZTIQTEBNP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Proposal: Allow non-default after default arguments
On 11/9/21 3:24 PM, Terry Reedy wrote:
On 11/9/2021 1:52 PM, Sebastian Rittau wrote:
Am 09.11.21 um 19:26 schrieb Terry Reedy:
The signature of Sebastian's function with honest parameter names is
foo(x_or_y, required_y=_NotGiven, /). It is the 2nd argument, not
the first, that is optional, as with range. If required_y is not
given, than x_or_y must be y, and x is given a default that is not
part of the signature because it is explicitly bound when called. If
required_y *is* given, then x_or_y can be x.
Just to clarify: This proposal works differently than how range()
works. foo(3) would be illegal as the required second parameter ("y")
is missing.
No it is not. If there is one required positional parameter and one
supplies one positional argument, then that argument must be bound to
that parameter name.
This can be solved by either supplying both "x" and "y", e.g.
foo(None, 3), or by using a named parameter for "y": foo(y=3).
You are asking that 'x' be required if 'y' is passed by position but
not if 'y' is passed by name. This is contradictory.
Note that range does not allow passing by keyword and I specified the
same for foo. If you make 'y' keyword only, then there is no problem
making 'x' optional.
the honest names are foo(x=None, y) in my proposal.
No, because you want 'x' is required or not depending on how 'y' is
passed.
One big issue with that method is there are surprise traps.
Given that definition, and a example function defined as:
def fun(x=None, y):
then if in future we want to add a default to y, we can't as it would be
a silent breaking change for a call like fun(2).
Now, if that call needed to be fun(y=2) then we avoided that break.
By first feeling is that the problems caused by skipping optional
positional parameters is enough to not make it worth it.
There is also that fact that if we initially require the y only call to
need to be a keyword parameter, but still be required and could be
positional if both are provided, we could later allow it to be
positional if that seems REALLY important to do, but it is much harder
to take back a syntax that has been given.
--
Richard Damon
___
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/XN6L7VXZFOLAX7BXQV3VIYWSMX3XKIHZ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The list.sort(reverse=True) method not consistent with description
On 10/30/21 11:46 AM, Raymond Bisdorff wrote: Dear Python developers, The help(list) shows in a python console the following documentation string for the list.sort() method. sort(self, /, *, key=None, reverse=False) | Sort the list in ascending order and return None. | | The sort is in-place (i.e. the list itself is modified) and stable (i.e. the | order of two equal elements is **maintained**). Please notice the following inconsistency in Python3.10.0 and before of a sort(reverse=True) result: >>> L = [(1, 'a'), (2, 'b'), (1, 'c'), (2, 'd'), (3, 'e')] >>> L.sort(reverse=True) >>> L >>> [(3, 'e'), (2, 'd'), (2, 'b'), (1, 'c'), (1, 'a')] it should be: >>> L = [(1, 'a'), (2, 'b'), (1, 'c'), (2, 'd'), (3, 'e')] >>> reverseTuplesSort(L) [(3, 'e'), (2, 'b'), (2, 'd'), (1, 'a'), (1, 'c')] Same inconsistency appears when using a sorting key. Passing easily unnoticed may produce unexpected and potentially wrong ranking results. Best Regards, RB Why do you thing (1,'a') should be 'bigger' than (1, 'c'), or (2,'b') bigger than (2,'d')? Tuples don't sort on just the first element, but on all their elements in order if the previous ones are the same. -- Richard Damon ___ 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/HHW6YZOYPSN4JXBEKHCI73TKDM4CPWWB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks
On 5/8/21 10:16 PM, Jim J. Jewett wrote: > Antoine Pitrou wrote: >> On Sat, 8 May 2021 02:58:40 + >> Neil Schemenauer nas-pyt...@arctrix.com wrote: >>> It would be cool if we could mmap the pyc files and have the VM run >>> code without an unmarshal step. >>> What happens if another process mutates or truncates the file while the >> CPython VM is executing code from the mapped file? Crash? > Why would this be any different than whatever happens now? Just because it > is easier for another process to get (exclusive) access to the file if there > is a longer delay between loading the first part of the file and going back > for the docstrings and lnotab? > > -jJ I think the issue being pointed out is that currently, when Python opens the .pyc file for reading and keeps the file handle open, that will block any other process from opening the file for writing, and thus can't change the contents under it. Once it is all done, it can release the lock as it won't need to read it again. if it mapped the file into its address space, it would need a similar sort of lock, but need to keep if for the FULL execution of the program, so that no other process could change the contents behind its back. I think normal mmapping doesn't do this, but if that sort of lock is available, then it probably should be used. -- Richard Damon ___ 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/QQHLCQC4UUWLM6HWHGOJ5SYCGBOO2LNS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: 3.10 change (?) for __bool__
On 1/12/21 10:53 AM, Mark Shannon wrote: > Hi everyone, > > Should the optimizer eliminate tests that it can prove have no effect > on the control flow of the program, even if that may eliminate some > side effects in __bool__()? > > For several years we have converted > > if a and b: > ... > > to > > if a: > if b: > ... > > which are equivalent, unless bool(a) has side effects the second time > it is called. > > In master we convert `if x: pass` to `pass` which is equivalent, > unless bool(x) has side effects the first time it is called. This is a > recent change. > > This is one of those "easy to fix, if we can decide on the semantics" > bugs. > > > Submit your thoughts to https://bugs.python.org/issue42899, please. > > Cheers, > Mark. One key point about 'and' and 'or' is that those operators are defined to be 'short circuiting', i.e. that with a and b, that if a is false, then b is not evaluated at all. This can be important if a is a condition that test if the expression b is 'safe' to evaluate. In fact, isn't it true that 'a and b' is defined to be the equivalent to: 'a if not a else b' so b doesn't need to be evaluated unless a is truthy. I know that I would be very surpised if a statement like if foo(): pass ended up optimizing itself and not calling foo(), which is only one step away from the quoted case of if b: pass which is the equivalent to if b.__bool__(): pass Yes, perhaps there is more of an expectation that __bool__() is innocuous, but is that a an assumption that should be baked into the language. -- Richard Damon ___ 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/HODNO42SFFRFX4IJY5K562YHT2MTIHIQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Why does "except Ex as x" not restore the previous value of x?
On 11/17/20 12:16 PM, Chris Angelico wrote: > On Wed, Nov 18, 2020 at 4:08 AM Richard Damon > wrote: >> One comment about having the exception handler 'save state' and restore >> it is that frequently the purpose of the exception handler is TO make >> changes to outer variable to fix things up based on the exception. >> >> I could see the desire of a way to create an internal scope of sorts and >> create names limited to that scope, but wouldn't want such a scope being >> anywhere automatic, and likely what would make more sense is defining a >> particular name (or names) to have a limited scope. > The ONLY variable that would be special is the one named in the > "except Exc as e:" clause. Everything else would follow the normal > rules. This is the only variable that is currently special, and ti'd > be the only one that ever needs to be special (since it has the > refloop that makes memory management harder). > > ChrisA My main thought on that variable, is I would expect it to have a good name that implies it is an exception, not something like e, unless you are reserving e for exceptions, so would be unlikely to shadow unless this is from a try block inside an except block that then return to more processing in the outer except block -- Richard Damon ___ 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/WKGWMDXXNYHT3JDBMVDLM5KYTMY4SRL7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Why does "except Ex as x" not restore the previous value of x?
One comment about having the exception handler 'save state' and restore it is that frequently the purpose of the exception handler is TO make changes to outer variable to fix things up based on the exception. I could see the desire of a way to create an internal scope of sorts and create names limited to that scope, but wouldn't want such a scope being anywhere automatic, and likely what would make more sense is defining a particular name (or names) to have a limited scope. ___ 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/A5LY2IPFQ6DPKIYAZAJTX6YNUBAVH2YL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Memory address vs serial number in reprs
On 7/19/20 4:30 PM, Thomas Moreau wrote: > Dear all, > > While it would be nice to have simpler identifiers for objects, it > would be hard to make it work for multiprocessing, as objects in > different interpreter would end up having the same repr. Shared > objects (locks) might also have different serial numbers depending on > how many objects have been created before it is communicated to the > child process. > > regards > Thomas > > My guess is that these numbers are the 'id()' of the object, which as an implementation detail in CPython is the object address. If some other method was chosen for generating the object id, then by necessity, there would need to be a method to let multiple interpreters keep the number unique, perhaps some bits being reserved for an interpreter id, and the rest be a serial number. -- Richard Damon ___ 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/ZUEK3LQ2PBGXG4KZ2466EDNIDGNLAWR2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
> On Jul 16, 2020, at 1:36 PM, Chris Angelico wrote: > > On Fri, Jul 17, 2020 at 3:25 AM Federico Salerno > wrote: >> Tools should adapt to the language, not the other way around. If things had >> to be done the way they had always been done, without any change, for fear >> of people not being used to it, we wouldn't even have Python at all. People >> learn and adapt. It seems like a small price to pay in exchange for >> consistency and removal of ambiguity, considering people will still have to >> learn the new feature one way or another. >> > > But consistency is exactly what you'd be destroying here. Python is > extremely consistent in that you ALWAYS indent after a line ends with > a colon, and what comes after it is logically contained within that > statement. It's about whether *people* can handle it, more than > whether tools can, and the consistency helps a lot with that. > > ChrisA > One question that comes to mind, does match NEED a colon at the end of it? If it didn’t have the colon, it wouldn’t need the indent for the following lines. ___ 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/M7CVHHBR5IGIUCFH4Y7S6I7FQWXTEE64/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup
On 7/7/20 10:08 PM, Rob Cliffe via Python-Dev wrote: > Why not use '=' to distinguish binding from equality testing: > case Point(x, =y): # matches a Point() with 2nd parameter equal to > y; if it does, binds to x. > > This would allow a future (or present!) extension to other relative > operators: > case Point(x, >y): > (although the syntax doesn't AFAICS naturally extend to specifying a > range, i.e. an upper and lower bound, which might be a desirable thing > to do. > Perhaps someone can think of a way of doing it). > > Whether > case =42: > case 42: > would both be allowed would be one issue to be decided. > Rob Cliffe My preference would be that we mark where to bind as opposed to what is a constant. Forgetting to mark a constant that has been bound to a name runs the risk of changing that 'constant' (since Python doesn't support marking a name as a constant). Forgetting to mark a name to bind may likely cause a run time error if it hasn't been bound yet, or at the very least probably fails in a 'safer' way. I think forgetting to add a special mark is a much more likely error than adding a mark by mistake (unless the mark is just havig a dot in the name). -- Richard Damon ___ 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/NMFVBR433E6UEGEEJAS6I6NNXPK7W4OM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.
On 7/2/20 10:19 AM, Victor Stinner wrote: > Do you mean UTF-16 and UTF-32? UTF-16 supports the whole Unicode > character set but uses the annoying surrogate pairs for characters > outside the BMP.* Minor quibble, UTF-16 handles all of the CURRENTLY defined Unicode set, and there is a currently a promise not to extend Unicode past that, but at some point they may need to break that promise. UTF-8, as previously defined (and could be again) easily handles U+ to U+7FFF. UTF-16 can handle via the surrogate pairs U+ to U+0010 and stop there, To extend past that would require some form of heroics, which is the reason that U+0010 is currently defined as the highest possible code point, as to allow a higher value breaks UTF-16, and there currently isn't a desire to do so. At some point in the distant future, we may run out of 'valid' code points, and this promise will need to be broken. UTF-16 grew out of a need to fix what has become UCS-2, which is the encoding used for earlier Unicode standards, before the need for code points above U+ (now the BMP) was seen. -- Richard Damon ___ 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/HJ7R5Q25EVCSBS7CZFZ5CNYITXOLWWFG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Please refrain from posting on the PEP 8 threads for 24 hours
On 6/30/20 4:32 PM, Tim Peters wrote: > [Victor Stinner ] >> If someone continues to feed the PEP 8 discussion, would it be >> possible to change their account to require moderation for 1 day or >> maybe even up to 1 week? I know that Mailman 3 makes it possible. > I see no such capability. I could, for example, manually fiddle > things so that messages from your email address are held for > moderation, but that would persist until I manually undid it egain. > > But there seem to be many things Mailman 3 is theoretically capable of > that aren't available via the list owner web UI. That's the only admin > access I have (or want). I've never heard of it having the ability to automatically time out a moderation flag. What could be done (I think Mailman3 has it) is put a filter on the topic subject to hold those messages for moderation, and then remove that after things calm down. That depends on the moderator being willing to take on that job (like the graphite rods in a reactor). -- Richard Damon ___ 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/UP2JEEF2XKSENJT4GGOLDSIT2DB3Q5W4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change
On 6/30/20 12:18 PM, Jim F.Hilliard wrote: > On Tue, 30 Jun 2020, 17:36 Piper Thunstrom, <mailto:pathunst...@gmail.com>> wrote: > > It specifically > was chosen to avoid "lower class" usages and things like AAVE (though > that term would not exist for decades after the movement reached a > furor). > > > I mean, surely not only did it exclude "lower class" terms and AAVE > (African American vernacular English, for the rest who don't do well > with acronyms) it also excluded a number of dialects used by groups of > all colours and backgrounds. I don't think I'd find any Australian > words in there nor any Scottish ones, would I? > > I don't see how standard English is a white supremacist construct. I > see it as an intersection of most of the dialects around, as a means > to optimize communication by following a common set of guidelines. > > Can you elaborate on why you view this as being white supremacy? > I agree with this, and for one very good reason, old, staid, sooty and stuffy language has a very big advantage for communicating, and that is being what it is, it tends to change slowly and people are likely to be able to understand it. Local vernaculars, almost by definition change much more rapidly and aren't as wide spread, so it is much more likely that there are many terms and constructions in them will be not well understood (if understood at all) without having to do a lot of research, and even then you may need to figure out which meaning was meant. If your goal is to communicate, going to the old core is usually the best. -- Richard Damon ___ 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/U3IGMRZ3GB7P2C4P77L2XFJPPSJQKRIL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.
On 6/30/20 8:43 AM, Emily Bowman wrote: > I completely agree with this, that UTF-8 has become the One True > Encoding(tm), and UCS-2 and UTF-16 are hardly found anywhere outside > of the Win32 API. Nearly all basic emoji can't be represented in UCS-2 > wchar_t, let alone composite emoji. > > So how to make that C-compatible? Make everything a void* and it just > comes back with as many bytes as it gets? Actually, in C you would tend to represent UTF-8 as a char* (or maybe an unsigned char*) type. This points out that straight 'ASCII' strings are also UTF-8, and that many of the string functions will actually work ok with UTF-8 strings. This was an intentional part of the design of UTF-8. Anything looking for specific character values will tend to 'just work', as long as those values really represent a character. The code also needs to take account of that now bytes != characters, so if you want to actually count how many characters are in a string, you need to be aware, and avoid splitting a string in the middle of a code-point, but a lot will still just work. -- Richard Damon ___ 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/YQWLGMN2M4JDVFSOYGFMOPUB7QAAWH2U/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.
On 6/30/20 7:53 AM, M.-A. Lemburg wrote: > Since the C world has adopted wchar_t for this purpose, it's the > natural choice. I would disagree with this comment. Microsoft Windows has chosen to use 'wchar_t' for Unicode, because they adopted UCS-2 before it morphed into UTF-16 due to the expansion of Unicode above 16 bits. The *nix side of the world has chosen to use UTF-8 as the preferred way to store Unicode characters. Also, in Windows, wchar_t doesn't really meet the requirements for what C defines wchar_t to mean, as wchar_t is supposed to represent every character as a single unit, and thus would need to be at least a 21 bit type (typically, it would be a 32 bit type), but Windows makes it a 16 bit type due to ABIs being locked before the Unicode expansion. -- Richard Damon ___ 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/TA2ITVZY6ZGH2Y42JAXD243RSG7MONTV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments
On 6/29/20 7:35 AM, Jim F.Hilliard wrote: > I believe I'm not the only one with this question but, how is Strunk & > White connected with white supremacy? > > Scanning through this thread, its wikipedia page and doing quick > google search, I wasn't able to find something tangible. > > > Best Regards, > * > * > Jim Fasarakis Hilliard A somewhat flippant answer (hope I don't get in trouble for it) is because it defines the 'proper' use of English to be what some ancient 'White Guys' said it was as opposed to how some other 'Non-White' guys use it, and those 'White Guys' were, at least in part, the people the white supremacy came from, i.e., guilt by association. -- Richard Damon ___ 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/IHRA5WM6KOPMSPAVD3LK53IKFXFL6E2B/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments
On 6/29/20 6:22 AM, Nathaniel Smith wrote: > and describes the > old text as a "relic", which is another way of saying that the > problems were only there by historical accident, rather than by anyone > intentionally keeping it there. I would say that say that I have seen the term "relic" being used as a 'weaponized' word to imply that the old thing WAS there intentionally as a repressive measure. I am not saying that this usage was intended to be used that way, but just as the old wording was taken as offensive to some due to implication, I can see that message as offensive to others due to implication, all because some people are easy to offend. -- Richard Damon ___ 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/6EN5RNF5CFDKCF3ZYQV53XH5KTBCSAQ6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The Anti-PEP
On 6/28/20 11:02 AM, Chris Angelico wrote: > Yep! A number of PEPs have "Objections" sections. I think that'd be a > good title for it. Yes, that was my thought. Have the PEP author include a summary of the major objections, and their defense to those objections. (The presence of the defense doesn't mean that the object HAS been overcome, but documents the authors opinion of why the PEP should be able to be accept dispite that objection, the final decision still will rest on the Steering Committee or their delegate). If the Objections section is well written, then opponents can refer to the section and simply restate their objection, and it will somewhat organize the opposition. If the Objections section is NOT well written, that might be a sign that the PEP needs work as the author doesn't seem to have understood some of the objections, and cleaning up that section may bring more clarity to the PEP as a whole. -- Richard Damon ___ 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/OYACTECWUFMOOKXGY5KJUGRSIEDSEZJD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching
On 6/27/20 5:36 AM, Stephen J. Turnbull wrote:
> Richard Damon writes:
>
> > I thought _ was also commonly used as:
> >
> > first, -, last = (1, 2, 3)
> >
> > as a generic don't care about assignment.
>
> It is. But there are other options (eg, 'ignored') if '_' is used for
> translation in the same scope.
>
> > I guess since the above will create a local, so not overwrite a
> > 'global' function _ for translations, so the above usage works as
> > long as that function (or whatever namespace you are in) doesn't
> > use _ for translations.
>
> Exactly.
>
> > As long as the bindings in match also make the symbol a local
> > (which seems reasonable) then you would get a similar restriction.
>
> It's quite different. First, it surely won't make other symbols
> match-local. Of course there will be times when you do all the work
> inside the match statement. But often you'll want to do bindings in a
> match statement, then use those outside. The second problem is that
> this use of '_' isn't optional. It's part of the syntax. That means
> that you can't use the traditional marking of a translateable string
> (and it's not just tradition; there is a lot of external software that
> expects it) in that scope.
>
> So it's practically important, if not theoretically necessary, that
> 'case _' not bind '_'.
>
> Steve
I wasn't imply local to the match statement, but if the match is used
inside a function, where using the binding operatior = will create a
local name, even if there is a corresponding global name that matches
(unless you use the global statement), will a match statement that binds
to a name that hasn't bee made a local name by having an explicit
assignment to it, actually bind to a global that might be present, or
will it create a local? My first feeling is that binding to the global
would be surprising.
i.e.
foo = 1
def bar(baz):
match baz:
case 1: print('baz was one')
case foo: print('baz was ', foo)
bar(2)
print(foo)
will this script create a new foo name inside bar, so that when we
return, the module global foo is still 1, or did be bind to the global
and change it?
Rebinding a global without a global statement would be unexpected
(normally we can mutate the global, but not rebind it)
--
Richard Damon
___
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/A2YKBTEHILHRNLN62LIPNAXCDG73ACD6/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching
On 6/25/20 6:48 PM, Emily Bowman wrote: > On Thu, Jun 25, 2020 at 3:41 PM Richard Damon > mailto:rich...@damon-family.org>> wrote: > > Actually, you could make _ less special by still binding the value to > > it, just make it special in that you allow several values to be bound, > and maybe just define that the result will be just one of the values, > maybe even specify which if you want. > > > Like Guido said above, the problem is that _ is already effectively > reserved for translated text. Combining the two would feel a bit > weird, but should still be possible. I thought _ was also commonly used as: first, -, last = (1, 2, 3) as a generic don't care about assignment. I guess since the above will create a local, so not overwrite a 'global' function _ for translations, so the above usage works as long as that function (or whatever namespace you are in) doesn't use _ for translations. As long as the bindings in match also make the symbol a local (which seems reasonable) then you would get a similar restriction. -- Richard Damon ___ 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/M5HWPDG43KGHKM6JVH7ZAGK6YT7OYVJR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching
On 6/25/20 10:42 AM, Greg Ewing wrote: > On 26/06/20 1:18 am, Rhodri James wrote: >> I will quickly and regularly forget that in this one place, "_" is >> special. > > You don't have to remember that it's special to understand what > 'case _' does. Even if it were treated as an ordinary name, it > would still have the effect of matching anything. > Actually, you could make _ less special by still binding the value to it, just make it special in that you allow several values to be bound, and maybe just define that the result will be just one of the values, maybe even specify which if you want. -- Richard Damon ___ 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/EIPWQ6W3CGNV5GGRDCCQ3M63CQFMYDM5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: REPL output bug
On 6/12/20 4:01 AM, Rob Cliffe via Python-Dev wrote:
> If I run the following program (using Python 3.8.3 on a Windows 10
> laptop):
>
> import sys, time
> for i in range(1,11):
> sys.stdout.write('\r%d' % i)
> time.sleep(1)
>
> As intended, it displays '1', replacing it at 1-second intervals with
> '2', '3' ... '10'.
>
> Now run the same code inside the REPL:
>
> Python 3.8.3 (tags/v3.8.3:6f8c832, May 13 2020, 22:20:19) [MSC v.1925
> 32 bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import sys, time
> >>> for i in range(1,11):
> ... sys.stdout.write('\r%d' % i)
> ... time.sleep(1)
> ...
> 12
> 22
> 32
> 42
> 52
> 62
> 72
> 82
> 92
> 103
> >>>
>
> It appears that the requested characters are output, *followed by* the
> number of characters output
> (which is the value returned by sys.stdout.write) and a newline.
> Surely this is not the intended behaviour.
> sys.stderr behaves the same as sys.stdout.
>
> Python 2 does NOT exhibit this behaviour:
>
> Python 2.7.18 (v2.7.18:8d21aa21f2, Apr 20 2020, 13:19:08) [MSC v.1500
> 32 bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import sys, time
> >>> for i in range(1,11):
> ... sys.stdout.write('\r%d' % i)
> ... time.sleep(1)
> ...
> 10>>>
> # displays '1', '2' ... '10' as intended.
>
> Best wishes
> Rob Cliffe
Is that what the REPL is defined to do? print the results of each
statement (unless it is None), so when working on it you don't need to
say print(...) everywhere.
--
Richard Damon
___
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/6QP2IUW6ZDYGUFUZNEORX3BPRMCSBWOF/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Please be more precise when commenting on PEP 611.
On 12/13/19 12:27 AM, Steven D'Aprano wrote: > On Wed, Dec 11, 2019 at 10:30:15PM -0500, Richard Damon wrote: > >> I will way that in my many years of >> programming experience I can't think of any great cases where a language >> as part of the language definition limited to 'size' of a program to >> good effect, > Good thing that's not what the PEP proposes then :-) > > The PEP talks about CPython implementation, not hard limits on all > Python compilers/interpreters. Not the way I read the PEP. It talks about changing the language. Under 'Enforcement' it admits it can't 'force' other implementations but says other implementations should generate the same errors unless doing so hurts performance, so it is a language change, not just limits for a given implementation. As I said originally, I have no problem with the idea of creating a variant implementation of CPython with this sort or documented limits to demonstrate that it does provide a real benefit. We would then be in a good place to determine the real costs and benefits, and one of the branches might just wither and die because it isn't useful enough anymore. > >> and generally such limits relegate a language into being >> seen as a 'toy language'. > The designers of C recognised that, in practice, compilers will have > limits. Rather than demanding "NO ARBITRARY LIMITS!!!" they specified > *minimum* levels for compliant compilers. Often quite low limits. > > Actual compilers often impose their own limits: > > https://gcc.gnu.org/onlinedocs/cpp/Implementation-limits.html > > https://www.cs.auckland.ac.nz/references/unix/digital/AQTLTBTE/DOCU_012.HTM Yes, as I said above, there is a big definition between an implementation of a language documenting some of its limits and the language definition itself limiting what the language can do. > > So if Mark's proposal relegates Python to a "toy language", we'll be in > good company with other "toys" that have implementation, or even > language, limits: > > > https://stackoverflow.com/questions/5689798/why-does-java-limit-the-size-of-a-method-to-65535-byte There is a big difference between limiting the size of a single method and limiting the total number of classes allowed in a program. The first can be largely gotten around by refactoring the method to be implemented in multiple methods, the latter can't be. > https://web.archive.org/web/20160304023522/http://programmers.stackexchange.com/questions/108699/why-does-javas-collection-size-return-an-int Yes, Java made a decision early in its life cycle to lock itself into fixed sized types, and > https://www.sqlite.org/limits.html These are a very different type of limits. These are defines that the programmer can change to establish what the various limits are. They can be increased or decreased as desired by the programmer (with natural upper limits based on the size of certain fundamental types). > > > (If you read only one of those five links, please read the last.) > > >> The biggest issue is that computers are >> growing more powerful every day, and programs follow in getting bigger, >> so any limit that we think of as more than sufficient soon becomes too >> small (No one will need more than 640k of RAM). > The beauty of this proposal is that since its an implementation limit, > not a law of nature, if and when computers get more powerful and > machines routinely have multiple zettabyte memories *wink* we can always > update the implementation. > > I'm not entirely being facetious here. There's a serious point. Unlike > languages like C and Java, where changes have to go through a long, > slow, difficult process, we have a much more agile process. If the PEP > is accepted, that doesn't mean we're locked into that decision for life. > Relaxing limits in the future doesn't break backwards compatibility. > > "What if computers get more powerful? Our limits will be obsolete!!!" > Naturally. Do you still expect to be using Python 3.9 in ten years time > with your fancy new uber-hyper-quantum ten thousand gigabyte computer? > Probably not. As hardware grows, and our needs grow, so can the > hypothetical limits. > > What is valuable are *concrete*, actual (not theoretical) examples of > where Mark's proposed limits are too low, so that we can get a realistic > view of where the potential tradeoffs lie: > > * lose this much functionality (code that did run, or might have run, > but that won't run under the PEP) > > * in order to gain this much in safety, maintainability, efficiency. > > > And before people jump down my throat again, I've already said -- on > multiple occassions -- that the onus is on Mark to demonstrate the > plausibility of any su
[Python-Dev] Re: Please be more precise when commenting on PEP 611.
I've been restraining myself from commenting in this threads, as I don't know enough details of the implementation of Python to make reasoned arguments on how much such limits would help in the efficiency for running a Python program. I will way that in my many years of programming experience I can't think of any great cases where a language as part of the language definition limited to 'size' of a program to good effect, and generally such limits relegate a language into being seen as a 'toy language'. The biggest issue is that computers are growing more powerful every day, and programs follow in getting bigger, so any limit that we think of as more than sufficient soon becomes too small (No one will need more than 640k of RAM). I COULD easily see on the other hand, the language stating that some implementations might impose certain limits like those being mentioned, and maybe provide lower limits of those limits, that barring system resource limits a program can expect to be able to use. If a program needs higher limits, it can use a less limiting implementation. I could see a fork of the current CPython implementation happening, where one path keeps the current lack of limits, and another branch tries imposing the limits to see how much benefit you really get. After seeing, one of the forks might just die off as not being needed any more. I would see those limits being added to the specific implementation that provide identifiable advantage to making the system better. Being done, at least initially, in a fork, there might not need to be a lot of discussion on exactly what limits to try imposing, as 'Python' as a base language wouldn't be changing, just some limits in a particular branch implementation. it still might make a lot of sense for some discussion to occur to find out if the limits being discussed are reasonable. Perhaps the one big disadvantage of this idea is that the person wanting to see what these limits might be able to do for the language would need to be more involved in seeing it happen, as there won't be the easy opportunity to propose a somewhat vague idea, get it approved, and have someone else stuck with the job of getting it done. -- Richard Damon ___ 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/QRP32EQPAQH53NR5NGHE55MCALEBJ5J6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP proposal to limit various aspects of a Python program to one million.
On 12/6/19 11:08 AM, 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. > The version of this philosophy that I have heard is normally: Zero, One, Many, or sometimes Zero, One, Two, Many, and occasionally Zero, One, Two, Three, Many. The Idea is that the handling of Zero of something is obviously a different case from having some of it. Having Just One of something often can be treated differently than multiple of it, and sometimes it makes sense to only allow 1 of the thing. Sometimes, having just Two of the things allows for some useful extra interactions, and can be simpler than an arbritary number, so sometimes you can allow just two, but not many. Similarly, there are some more rare cases where maybe allowing just 3 and not more can make sense. In general, for larger values, if you allow M, then there isn't a good reason to not allow M+1 (until you hit practical resource limits). I wouldn't extend that to 'infinity' as there is a big catagorical difference between an arbitrary 'many' and 'infinite', as computers being finite machines CAN'T actually have infinite of something without special casing it. (and if you special case infinite, you might not make the effort handle large values of many). -- Richard Damon ___ 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/EZGVTV6XRS3KFBWWPPJOEHC5LVNWEYQF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [SPAM?] Re: What to do about invalid escape sequences
On 8/10/19 7:05 AM, Chris Angelico wrote: > On Sat, Aug 10, 2019 at 6:39 PM Paul Moore wrote: >> There are *many* valid ways to write Windows pathnames in your code: >> >> 1. Raw strings >> 2. Doubling the backslashes >> 3. Using pathlib (possibly with slash as a directory separator, where >> it's explicitly noted as a portable option) >> 4. Using slashes >> >> IMO, using slashes is the *worst* of these. But this latter is a >> matter of opinion - I've no objection to others believing differently, >> but I *do* object to slashes being presented as the only option, or >> the recommended option without qualification. > Please expand on why this is the worst? > > ChrisA One big issue with trying to get use to using / on windows for the directory separator is that it doesn't work for many windows programs because on Windows the / character is defined to be the option character (instead of - for *nix) Yes, you can write your program to use the foreign convention of using - for options, and because the system calls accept either \ or / as the directory separator, paths which use the 'wrong' separator will work, but your program will be violating the conventions of the host environment. -- Richard Damon ___ 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/RMEUSPLAST7INRQQDLILW3IYETWDITMV/
Re: [Python-Dev] PEP 558: Defined semantics for locals()
On 5/27/19 2:05 PM, Terry Reedy wrote: > On 5/27/2019 9:52 AM, Richard Damon wrote: >> On 5/27/19 9:12 AM, Terry Reedy wrote: > >>> I believe that the situation is or can be thought of as this: there is >>> exactly 1 function locals dict. > > per function invocation, or more generally, as Guido said, per stack > frame. This part is obvious to me, but I should have been clearer. > >>> Initially, it is empty and >>> inaccessible (unusable) from code. Each locals() call updates the >>> dict to a current snapshot and returns it. >>> >> I had a similar concern, and one BIG issue with it being define this way >> is that you get a fundamental re-entrancy problem. If module a uses >> locals(), and then calls module b that uses locals(), module a has lost >> its usage. > > No. Sorry about being unclear. > Ok, if each function invocation gets its own dict, then the reentrancy issues go away. The fact that it isn't the 'active' dict, so you can't use it to modify the current state, but also you don't get a fresh copy each time (there is a single mutable dict that gets updated) seems to be an odd behavior and I can't see where it is an advantage to the user of the function, or where that makes it easier on the implementation. (But I could easy be missing something). -- Richard Damon ___ 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 558: Defined semantics for locals()
On 5/27/19 9:12 AM, Terry Reedy wrote: > On 5/27/2019 3:18 AM, Greg Ewing wrote: >> Chris Angelico wrote: >>> Except that it does. After calling locals() a second time, the result >>> of the *first* call will be updated to reflect changes. >> >> Yeow. That's *really* unintuitive. There had better be an extremely >> good reason for this behaviour. > > I believe that the situation is or can be thought of as this: there is > exactly 1 function locals dict. Initially, it is empty and > inaccessible (unusable) from code. Each locals() call updates the > dict to a current snapshot and returns it. > I had a similar concern, and one BIG issue with it being define this way is that you get a fundamental re-entrancy problem. If module a uses locals(), and then calls module b that uses locals(), module a has lost its usage. One implication of this is that then you really want ALL modules to define if they use the locals() function or not, then you get the question, does this 1 of apply across threads? does a call to locals in another thread make me lose my locals (or does each thread get its own version), if that is true then if you might possible be in a situation where threads are in play you MUST make the copy anyway, and do it fast enough that the GIL isn't released between the snapshot and the copy (if possible), C made this sort of mistake decades ago for some functions, not thinking about threads or re-entrancy, and had to create solutions to fix it. Let us not forget history and thus repeat it. Is there a fundamental reason that local needs to keep a single dict, as opposed to creating a new one for each call? The way it is currently defined, once it is called, the snapshot will stay forever, consuming resources, while if a new dict was created, the resource would be reclaimed after use. Yes, if called twice you end up with two copies instead of both being updated to the current, but if you WANTED to just update the current copy, you could just rebind it to the new version, otherwise you are just forcing the programmer to be making the copies explicitly. -- Richard Damon ___ 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] [SPAM?] Re: PEP 558: Defined semantics for locals()
On 5/25/19 5:09 PM, Nathaniel Smith wrote: > On Sat, May 25, 2019, 07:38 Guido van Rossum <mailto:gu...@python.org>> wrote: > > This looks great. > > I only have two nits with the text. > > First, why is the snapshot called a "dynamic snapshot"? What > exactly is dynamic about it? > > > It's dynamic in that it can spontaneously change when certain other > events happen. For example, imagine this code runs at function scope: > > # take a snapshot > a = locals() > > # it's a snapshot, so it doesn't include the new variable > assert "a" not in a > > # take another snapshot > b = locals() > > # now our first "snapshot" has changed > assert "a" in a > > Overall I'm happy with the PEP, but I'm still a bit uneasy about > whether we've gotten the details of this "dynamicity" exactly right, > esp. since the PEP promotes them from implementation detail to > language features. There are a lot of complicated tradeoffs so I'm > working on a longer response that tries to lay out all the options and > hopefully convince myself (and everyone else). > > -n To me that is a static snapshot of a dynamic environment, not a dynamic snapshot. The snapshot you get at THAT moment in time won't change, as time progresses, so that snapshot itself isn't dynamic. Calling something a 'dynamic snapshot' could be take to imply that the snapshot itself is dynamic, and thus changes at that environment changes (and you could pass that snapshot to some other place, and they could get a view of things just like you would see it there, -- Richard Damon ___ 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] PEPs from non-core devs now need a sponsor
On 3/8/19 8:09 AM, Alex Walters wrote: > I'm confused about this. Didn't you need someone with merge permissions > already to merge a pep into the pep repo? Isn't this just adding a layer of > paperwork to something that was already the case for all practical purposes? > > I would say the difference that before, the non-committer proposer just needed to convince some committer that the PEP was 'a good idea' and worth being discussed. Now, that person needs to persuade some committer that not only is it a good idea, but that it is worth the committer committing themselves to supporting the proposer through the process. -- Richard Damon ___ 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] Need discussion for a PR about memory and objects
On 11/18/18 7:32 AM, Nick Coghlan wrote: > On Sun, 4 Nov 2018 at 23:33, Steven D'Aprano wrote: >> On Sun, Nov 04, 2018 at 11:43:50AM +0100, Stephane Wirtel wrote: >>> In this PR [https://github.com/python/cpython/pull/3382] "Remove reference >>> to >>> address from the docs, as it only causes confusion", opened by Chris >>> Angelico, there is a discussion about the right term to use for the >>> address of an object in memory. >> Why do we need to refer to the address of objects in memory? > Following up on this discussion from a couple of weeks ago, note that > Stephane misstated Chris's question/proposal from the PR slightly. > > The context is that the data model documentation for objects currently > describes them as having an identity, a type, and a value, and then > uses "address in memory" as an analogy for the properties that the > object identity has (i.e. only one object can have a given identifier > at any particular point in time, but identifiers can be re-used over > time as objects are created and destroyed). > > That analogy is problematic, since it encourages the "object > identities are memory addresses" mindset that happens to be true in > CPython, but isn't true for Python implementations in general, and > also isn't helpful for folks that have never learned a lower level > language where you're manipulating pointers directly. > > However, simply removing the analogy entirely leaves that paragraph in > the documentation feeling incomplete, so it would be valuable to > replace it with a different real world analogy that will make sense to > a broad audience. > > Chris's initial suggestion was to use "license number" or "social > security number" (i.e. numbers governments assign to people), but I'm > thinking a better comparison might be to vehicle registration numbers, > since that analogy can be extended to the type and value > characteristics in a fairly straightforward way: > > - the object identity is like the registration number or license plate > (unique within the particular system of registering vehicles, but not > unique across systems, and may sometimes be transferred to a new > vehicle after the old one is destroyed) > - the object type is like the make and model (e.g. a 2007 Toyota > Corolla Ascent Sedan) > - the object value is a specific car (e.g. "that white Corolla over > there with 89000 km on the odometer") > > On the other hand, we're talking about the language reference here, > not the tutorial, and understanding memory addressing seems like a > reasonable assumed pre-requisite in that context. > > Cheers, > Nick. One issue with things like vehicle registration numbers is that the VIN of a vehicle is really a UUID, it is globally unique no other vehicle will every have that same ID number, and people may not think of the fact that some other ID numbers, like the SSN do get reused. Since the Python Object Identities can get reused after the object goes away, the analogy really needs to keep that clear, and not give the other extreme of a false impression that the ID won't get reused after the object goes away. -- Richard Damon ___ 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] Change in Python 3's "round" behavior
On 9/30/18 6:15 PM, Greg Ewing wrote: > Chris Angelico wrote: >> ]That >> means that any representable number actually has to indicate a range >> of values centered on that value. > > That's not always true -- it depends on the source of the > information. For example, a reading of 5 seconds on a clock > with 1 second resolution actually represents a value between > 5 and 6 seconds. > > So if you're fussy about rounding, you might want to round > clock readings differently from measurements on a ruler. > Actually it could be from 4+ to 6- seconds, say the first reading is 1, that could be anything from 1.000 to 1.999 and the second reading be 6, that could be from 6.000 to 6.999, thus the interval be from 6.000 - 1.999 = 4.001 tp 6.999 - 1.000 = 5.999 seconds. Now if you waited for the start time to roll over so you knew you were near 1.000, that would be different, but from just sampling you get ranges. Now if it was a stop watch that started at the beginning it depends on how it presents the time, it might respond 5 for 5.000 to 5.999 seconds, or it might intentionally round the data and say 5 from about 4.5 to 5.5. Now, one case where there is an intentional bias to the bottom is Map Grid Coordinate system, where you specify 1 meter resolution within a grid with 5 digits, but if you want to specify to less precision, the specification it to ALWAYS truncate so map coordinate 1234 represent the range from 12340. to 12349. -- Richard Damon ___ 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 the Contributor Agreement need my address?
On 9/9/18 3:57 PM, Antoine Pitrou wrote: > On Sun, 9 Sep 2018 15:15:36 -0400 > Terry Reedy wrote: >> On 9/9/2018 1:49 PM, Antoine Pitrou wrote: >>> On Sat, 8 Sep 2018 23:11:27 -0400 >>> "Joseph C. Sible" wrote: >>>> I'm used to signing CLA's that require nothing beyond a name and a check >>>> box. When I went to sign the PSF Contributor Agreement so I can submit a PR >>>> for CPython, I was surprised to see that it wants my address. Why does the >>>> Python Software Foundation need this, especially when nobody else does? >> I presume others are correct that an address helps as an identifier. > It probably does, though it's hardly perfect. Mostly it can serve as a > contact point, but these days an e-mail address might be more durable > than a postal address (and it's probably a much better identifier too). > A Name + Address is a practically perfect identifier, as most people have a specific legal address of residence and at that address it is very unlikely two people have identical legal names. It is this legal address and legal name that people should be using for these sorts of legal documents. Government tend to have a vested interest in keeping track of legal addresses as this tends to have implications in things like taxes, so piggy backing on this identification can help with identification for other purposes. There also tends to be official government documents that can track back your 'official' address over time, so confirming that you are the Joe Smith from 15 Main ST, Anytown USA, is possible. Try to think how you could legally prove you were or were not the owner of joe.sm...@example.com 10 years ago, where example.com is some major free email providers. -- Richard Damon ___ 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 the Contributor Agreement need my address?
On 9/8/18 11:46 PM, Tim Peters wrote: > [Joseph C. Sible >> I'm used to signing CLA's that require nothing beyond a name and a check >> box. When I went to sign the PSF Contributor Agreement so I can submit >> a PR for CPython, I was surprised to see that it wants my address. Why >> does the Python Software Foundation need this, especially when nobody >> else does? > So that our marketing partners can deliver exciting consumer shopping > opportunities directly to your front door ;-) > > Seriously, "nobody else does" shows you haven't looked much. For > example, the first two I just looked at also require a mailing > address: > > Apache CLA > https://www.apache.org/licenses/icla.pdf > > Android CLA > https://cla.developers.google.com/clas/new?domain=DOMAIN_GOOGLE=KIND_INDIVIDUAL > > So I'll guess that projects big enough to hire actual lawyers require > an address. As to why they want an address, you'll have to ask a > lawyer! There aren't any on this list. So, if you really want to > pursue this, I suggest you direct the question instead to the Python > Software Foundation, which deals with the project's legalities: > > p...@python.org > _ While I am not a lawyer, or even play on on TV, I can imagine that for such an agreement to really be enforced, they need to know who actually is agreeing to it. Just a name isn't a unique a unique identifier, so more information is needed. -- Richard Damon ___ 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] [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
On 5/18/18 9:20 AM, Ivan Pozdeev via Python-Dev wrote: > Since Python uses semantic versioning (https://semver.org), the > criterion for "what's new-worthy" changes is simple: they are _public > interface changes_ (which include visible changes to documented behavior). > (I maintain that changes to behavior that is not documented -- incl. > issue30399 -- are _not_ public interface changes, and whoever relies > on them does that on their own risk.) > Python does NOT use semantic versioning as features are allowed to be obsoleted and removed without a major version number change. Also the addition of a new keyword which breaks old code would not be allowed with semantic versioning. The basic rules of semantic versioning is that ANY program that uses documented features of version a.b.c will work on any version a.d.e where (d > b) or (d = b and e > c). If python did use semantic versioning then there would be no need to keep updates to older minor versions, once 3.7.0 was out, there would be no need for keeping the 3.6.x, 3.5.x, 3.4.x branch etc, as any program that was written for those older version would just work with the newer version. The need for those is proof that python does not use semantic versioning. If you wanted to map python version to a semantic versioning concept, the first two numbers of the version would correspond to what semantic versioning call the 'major revision' which is what is allowed to break backwards compatibility with API, with the first digit being major changes and the second minor but not fully backwards compatible changes. -- Richard Damon ___ 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
