[issue25021] product_setstate() Out-of-bounds Read

Roundup Robot added the comment: New changeset 8cc052c28910 by Kristján Valur Jónsson in branch '3.3': Issue #25021: Correctly make sure that product.__setstate__ does not access https://hg.python.org/cpython/rev/8cc052c28910 New changeset 4f85b6228697 by Kristján Valur Jónsson in branch '3.4':

[issue25021] product_setstate() Out-of-bounds Read

Changes by Kristján Valur Jónsson : -- stage: -> resolved ___ Python tracker ___ ___

Re: Terminology: "reference" versus "pointer"

On Saturday, September 12, 2015 at 10:02:40 PM UTC+5:30, Steven D'Aprano wrote: > On Sat, 12 Sep 2015 02:42 pm, Random832 wrote: > > > Anyway, maybe we do need a term to distinguish Python/C#/Java pointers > > from C/C++ pointers - maybe call it a "non-arithmetic" pointer, since > > the key thing

Re: Terminology: "reference" versus "pointer"

On Sat, 12 Sep 2015 10:46 pm, Rustom Mody wrote: > On Saturday, September 12, 2015 at 11:57:01 AM UTC+5:30, Ben Finney wrote: >> You've clearly committed to some ontology that just doesn't match the >> Python data model. > > How about lay-English ontology in which "point to" and "refer to" are

Re: Terminology: "reference" versus "pointer"

On Saturday, September 12, 2015 at 9:47:33 PM UTC+5:30, rurpy wrote: > Frankly, I feel a little insulted by people who presume that having > learned what a pointer is in C, that my brain is so rigid that I must > necessarily think that pointer means exactly what pointer means in C > forever

Re: Terminology: "reference" versus "pointer"

On Sun, 13 Sep 2015 02:17 am, ru...@yahoo.com wrote: > Having programmed in C in the past, Well, there's your problem. Like BASIC before it, anyone who has learned C is mentally crippled for life as a programmer *wink* > the model of Python I eventually > developed is very much (I think,

Re: Terminology: "reference" versus "pointer"

On Saturday, September 12, 2015 at 11:26:18 PM UTC+5:30, Akira Li wrote: > Rustom Mody writes: > > > On Saturday, September 12, 2015 at 8:11:49 PM UTC+5:30, Laura Creighton > > wrote: > >> In a message of Sat, 12 Sep 2015 05:46:35 -0700, Rustom Mody writes: > >> >How about lay-English ontology

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

On Sat, Sep 12, 2015 at 4:10 PM, Tim Peters wrote: > "A potential problem" with .astimezone()'s default is that it _does_ > create a fixed-offset zone. It's not at all obvious that it should do > so. First time I saw it, my initial _expectation_ was that it > "obviously"

Re: Terminology: "reference" versus "pointer"

Akira Li <4kir4...@gmail.com> writes: >Rustom Mody writes: >> viz. I have two variables (or names!) say a and b which look the same > a >> [[1,2],[1,2]] > b >> [[1,2],[1,2]] >> And yet doing > a[0][0] = "Oops!" >> gives a data structure one "Oops!" >> whereas

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: I'll probably ensure that all of the parsing errors contain "format string" or "f-string" or similar. That way the regex check is easier, and the user can search for it more easily. It remains to be seen how these are referenced in the documentation.

Re: Terminology: "reference" versus "pointer"

On 12/09/2015 23:34, rurpy--- via Python-list wrote: On 09/12/2015 04:14 PM, Emile van Sebille wrote: On 9/12/2015 12:58 PM, rurpy--- via Python-list wrote: The question is whether what "pointer" means in languages that use the word is*so* different than its meaning in the Python sense I

Re: Context-aware return

On Thursday, September 10, 2015 at 8:44:01 PM UTC-4, Denis McMahon wrote: > On Fri, 11 Sep 2015 03:54:14 +1000, Steven D'Aprano wrote: > > > If I did this thing, would people follow me down the street booing and > > jeering and throwing things at me? > > Yes > > >>> x = func() > >>> x > >>>

Re: Terminology: "reference" versus "pointer"

On 09/12/2015 10:32 AM, Steven D'Aprano wrote: > On Sat, 12 Sep 2015 02:42 pm, Random832 wrote: >[...] > Computer science and IT is *dominated* by a single usage for "pointer" -- > it's an abstract memory address. The fundamental characteristics of > pointers are: Just upthread, you claimed

Re: Are there any "correct" implementations of tzinfo?

Random832 writes: > I was trying to find out how arithmetic on aware datetimes is "supposed > to" work, and tested with pytz. When I posted asking why it behaves this > way I was told that pytz doesn't behave correctly according to the way > the API was designed. The

Re: Python handles globals badly.

On 12/09/2015 17:29, Dennis Lee Bieber wrote: On Sat, 12 Sep 2015 05:11:46 +0100, Mario Figueiredo declaimed the following: On 12-09-2015 03:35, Mark Lawrence wrote: Ada took over from CORAL in the UK, at least in military projects. It was also used in the aircraft

Re: Terminology: "reference" versus "pointer"

On Sun, Sep 13, 2015 at 9:39 AM, Rustom Mody wrote: > To which we have Chris saying CPython ≠ Python > Which reminds me of another definition > Fig-Leaf: A device for converting poor porn into high art > > Even in languages like C with an ISO standard adhering to the

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: After discussing it with Guido, I've removed the ability to combine 'f' with 'u'. -- ___ Python tracker ___

Re: Terminology: "reference" versus "pointer"

Rustom Mody writes: > On Saturday, September 12, 2015 at 8:11:49 PM UTC+5:30, Laura Creighton wrote: >> In a message of Sat, 12 Sep 2015 05:46:35 -0700, Rustom Mody writes: >> >How about lay-English ontology in which "point to" and "refer to" are fairly >> >synonymous? >>

Are there any "correct" implementations of tzinfo?

I was trying to find out how arithmetic on aware datetimes is "supposed to" work, and tested with pytz. When I posted asking why it behaves this way I was told that pytz doesn't behave correctly according to the way the API was designed. The tzlocal module, on the other hand, appears to simply

[issue23992] multiprocessing: MapResult shouldn't fail fast upon exception

Davin Potts added the comment: As an aside: issue24948 seems to show there are others who would find the immediate-multiple-error_callback idea attractive. -- ___ Python tracker

[issue20917] Idle: Enhance font change notification system

Mark Roseman added the comment: The new 'component' infrastructure provides the mechanism for passing these kinds of notifications around. Allowing extensions (in whatever form they'll exist with the new stuff) to take part in this notification mechanism would be a small (and sensible)

Re: Terminology: "reference" versus "pointer"

On Sunday, September 13, 2015 at 4:05:21 AM UTC+5:30, ru...@yahoo.com wrote: > On 09/12/2015 04:14 PM, Emile van Sebille wrote: > > On 9/12/2015 12:58 PM, rurpy--- via Python-list wrote: > > > >> The question is whether what "pointer" means in languages that use the > >> word is*so* different

Re: Terminology: "reference" versus "pointer"

On Saturday, September 12, 2015 at 7:15:18 PM UTC-4, Mark Lawrence wrote: > On 12/09/2015 23:34, rurpy--- via Python-list wrote: > > On 09/12/2015 04:14 PM, Emile van Sebille wrote: > >> On 9/12/2015 12:58 PM, rurpy--- via Python-list wrote: > >> > >>> The question is whether what "pointer" means

Re: Terminology: "reference" versus "pointer"

On Sun, Sep 13, 2015 at 3:24 AM, Steven D'Aprano wrote: > Note: when I write my own Python implementation, all IDs will be negative > odd numbers. When I build my own CPU architecture, all memory addresses will be negative odd numbers, so people think your Python uses

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

Oops, pressed the wrong reply button and it didn't include the datetime list. On Sat, Sep 12, 2015, at 14:53, Tim Peters wrote: > > I was trying to find out how arithmetic on aware datetimes is > > "supposed to" work, and tested with pytz. When I posted asking why > > it behaves this way I was

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

On Sat, Sep 12, 2015 at 3:41 PM, Tim Peters wrote: > > If there are not, maybe the intended semantics should go > > by the wayside and be replaced by what pytz does. > > Changing anything about default arithmetic behavior is not a > possibility. This has been beaten to

[issue24965] Implement PEP 498: Literal String Formatting

Jelle Zijlstra added the comment: Thanks! Here are a few more cases I came across with the existing implementation: >>> f"{'a\\'b'}" File "", line 1 SyntaxError: missing '}' in format string expression I believe this is valid and should produce "a'b". >>> f"{x!s!s}" File "", line 1

Re: Terminology: "reference" versus "pointer"

Jussi Piitulainen writes: > I think the best way is to say that a[0] and a[1] are the same object, > while b[0] and b[1] are different objects. Sure, you can *say* that. But how do you draw it on a diagram with sticky notes or parcel tags or whatever? --

Re: Terminology: "reference" versus "pointer"

Picking a post to respond to, more or less at random... On Saturday, September 12, 2015 at 9:14:00 AM UTC-6, Rustom Mody wrote: > On Saturday, September 12, 2015 at 8:11:49 PM UTC+5:30, Laura Creighton wrote: > > In a message of Sat, 12 Sep 2015 05:46:35 -0700, Rustom Mody writes: > > >How about

Re: Python handles globals badly.

On 2015-09-12 06:22, Skybuck Flying wrote: "Michael Torrie" wrote in message news:mailman.384.1442016089.8327.python-l...@python.org... On 09/11/2015 03:50 PM, Skybuck Flying wrote: Something which python does not seem to do currently ?! So that's weird. I will leave it at that for now.

Re: Python handles globals badly.

On 2015-09-12 17:29, Dennis Lee Bieber wrote: On Sat, 12 Sep 2015 05:11:46 +0100, Mario Figueiredo declaimed the following: On 12-09-2015 03:35, Mark Lawrence wrote: Ada took over from CORAL in the UK, at least in military projects. It was also used in the aircraft

Re: Terminology: "reference" versus "pointer"

On Sun, 13 Sep 2015 02:54 am, Rustom Mody wrote: > This is from the docs > https://docs.python.org/3/library/functions.html#id Yes, what of it? What point do you think you are making? > id(object) > > Return the "identity" of an object. This is an integer which is > guaranteed to be

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[] > My context is that I am working on an idea to include utc offsets in > datetime objects (or on a similar object in a new module), as an > alternative to something like a "fold" attribute. and since "classic > arithmetic" is apparently so important, Love it or hate it,

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

On Sat, Sep 12, 2015, at 14:53, Tim Peters wrote: > > I was trying to find out how arithmetic on aware datetimes is > > "supposed to" work, and tested with pytz. When I posted asking why > > it behaves this way I was told that pytz doesn't behave correctly > > according to the way the API was

string_formatter 1.0.1 released

string_formatter is a backport of the 3.4.1+ string.Formatter class, to 2.7, 3.3 and 3.4.0. This allows the use of empty keys {} in its format strings. At the same time it solves an existing (at least until 3.5.0.rc3) bug in string.Formatter, breaking with the use of nested empty keys. Python

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

>>> If there are not, maybe the intended semantics should go >> > by the wayside and be replaced by what pytz does. >> Changing anything about default arithmetic behavior is not a >> possibility. This has been beaten to death multiple times on this >> mailing list already, and I'm not

[issue24948] Multiprocessing not timely flushing stack trace to stderr

Davin Potts added the comment: If I understand your motivations correctly, I'd restate them as: you want a mechanism for being immediately notified of an exception in a parent process without waiting on any child processes of that parent to finish and furthermore propose this should be the

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

On Sat, Sep 12, 2015 at 2:24 PM, Alexander Belopolsky < alexander.belopol...@gmail.com> wrote: > > On Sat, Sep 12, 2015 at 4:10 PM, Tim Peters wrote: > >> "A potential problem" with .astimezone()'s default is that it _does_ >> create a fixed-offset zone. It's not at all

[issue24862] subprocess.Popen behaves incorrect when moved in process tree

Andre Merzky added the comment: This is patch is meant to be illustrative rather than functional (but it works in the limited set of cases I tested). -- keywords: +patch Added file: http://bugs.python.org/file40448/subprocess.py.diff ___ Python

[issue24965] Implement PEP 498: Literal String Formatting

Jelle Zijlstra added the comment: Is this behavior intentional? >>> str = len >>> x = 'foo' >>> f'{x!s}' '3' >>> '{!s}'.format(x) 'foo' Or similarly: >>> import builtins >>> del builtins.repr >>> f'{x!r}' Traceback (most recent call last): File "", line 1, in NameError: name 'repr' is not

Re: Terminology: "reference" versus "pointer"

On Sun, 13 Sep 2015 03:12 am, Rustom Mody wrote: > Best I can see, the people frothing at the mouth that python has no > pointers are basically saying that "non-first-class" == "non-existent" Not at all. In Python, at least, all values are first-class, but that's not the case with all languages

Re: Are there any "correct" implementations of tzinfo?

On 09/12/2015 12:23 PM, Random832 wrote: > I was trying to find out how arithmetic on aware datetimes is "supposed > to" work, and tested with pytz. When I posted asking why it behaves this > way I was told that pytz doesn't behave correctly according to the way > the API was designed. The tzlocal

Re: Are there any "correct" implementations of tzinfo?

On Sat, Sep 12, 2015, at 14:36, Carl Meyer wrote: > Well, the problem is that because datetime doesn't include any way to > disambiguate ambiguous times, it's not really possible to implement > complex timezones in a way that is both correct (if your definition of > correct includes "timezone

Re: Random MAC generator error

On Sun, 13 Sep 2015 00:50:24 +0530, Robert Clove wrote: > import random # > > global mac1 > def randomMAC(): > mac = [ 0x00, 0x16, 0x3e, > random.randint(0x00, 0x7f), random.randint(0x00, 0xff), > random.randint(0x00, 0xff) ] > return ':'.join(map(lambda

Re: Terminology: "reference" versus "pointer"

On 09/12/2015 04:14 PM, Emile van Sebille wrote: > On 9/12/2015 12:58 PM, rurpy--- via Python-list wrote: > >> The question is whether what "pointer" means in languages that use the >> word is*so* different than its meaning in the Python sense > > I can't find a single reference to pointer in

Re: Terminology: "reference" versus "pointer"

On Sun, Sep 13, 2015 at 2:54 AM, Rustom Mody wrote: >> Insisting that Python has pointers is like insisting that you use a text >> editor by flipping bits. "What happens if I press Ctrl-X?" "Well, these >> bits on the screen flip from black to white, these bits flip from

Re: Terminology: "reference" versus "pointer"

On Saturday, September 12, 2015 at 10:21:08 PM UTC+5:30, Steven D'Aprano wrote: > Python values are not addresses. Python values are objects. Which means for example...??? Atoms? Stars? People? Countries? > Addresses, even when they exist, are not accessible in the Python language. And you

[issue24965] Implement PEP 498: Literal String Formatting

Jelle Zijlstra added the comment: I've started working on implementing this feature in Cython and I'd like to confirm a few edge cases: - f'{ {1: 2\N{RIGHT CURLY BRACKET}[1]}' == '2' (string escape rules work even within the expressions) - f'{ '''foo''' }' is a syntax error - f'{ """foo

Re: Terminology: "reference" versus "pointer"

On 09/12/2015 11:48 AM, Steven D'Aprano wrote: > On Sun, 13 Sep 2015 02:17 am, ru...@yahoo.com wrote: > [...] >> the model of Python I eventually >> developed is very much (I think, haven't read the whole thread) like >> Random832's. I think of boxes (objects) with slots containing "pointers" >>

Re: Terminology: "reference" versus "pointer"

Rustom Mody writes: a > [[1,2],[1,2]] b > [[1,2],[1,2]] > And yet doing a[0][0] = "Oops!" > gives a data structure one "Oops!" > whereas doing it to b mysteriously gives 2 > > Best I can see you can only explain this > seemingly-similar-but-structurally-different > with

Re: Terminology: "reference" versus "pointer"

Rustom Mody writes: > On Saturday, September 12, 2015 at 11:26:18 PM UTC+5:30, Akira Li wrote: >> Rustom Mody writes: >> >> > On Saturday, September 12, 2015 at 8:11:49 PM UTC+5:30, Laura Creighton >> > wrote: >> >> In a message of Sat, 12 Sep 2015 05:46:35 -0700,

Re: Python handles globals badly.

On 12-09-2015 18:09, MRAB wrote: > On 2015-09-12 17:29, Dennis Lee Bieber wrote: >> But no one had tested the algorithm with the rate of change the >> Ariane >> 5 could produce -- so an algorithm that was developed for, and safe with, >> the smaller Ariane suddenly went "something's wrong --

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: This patch fixes triple-quoted strings, plus a few bugs. I'm going to commit it tomorrow, barring any unforeseen issues. -- Added file: http://bugs.python.org/file40447/pep-498-5.diff ___ Python tracker

Re: Terminology: "reference" versus "pointer"

On 9/12/2015 12:58 PM, rurpy--- via Python-list wrote: The question is whether what "pointer" means in languages that use the word is*so* different than its meaning in the Python sense I can't find a single reference to pointer in the python docs outside of ctypes. What is its python

[issue24862] subprocess.Popen behaves incorrect when moved in process tree

Andre Merzky added the comment: Yes, I have a workaround (and even a clean solution) in my code. My interest in this ticket is more academic than anything else :) Thanks for the pointer to issue1731717. While I am not sure which 'comment at the end' you exactly refer to, the whole

Re: Terminology: “reference” versus “pointer”

On Sat, 12 Sep 2015 03:03 pm, Random832 wrote: > Yes I am. You're just making the implicit assumption that a "value" has > to be a number, and I was ignoring that assumption. The value is the > address of an object. The unknown, unknowable, and in fact possibly non-existent address of an object.

Re: Terminology: "reference" versus "pointer"

On 9/12/2015 9:54 AM, Rustom Mody wrote: On Saturday, September 12, 2015 at 10:02:40 PM UTC+5:30, Steven D'Aprano wrote: On Sat, 12 Sep 2015 02:42 pm, Random832 wrote: Anyway, maybe we do need a term to distinguish Python/C#/Java pointers from C/C++ pointers - maybe call it a "non-arithmetic"

Re: Python handles globals badly.

On 9/11/2015 10:22 PM, Skybuck Flying wrote: I didn't learn anything from this posting, sorry ! ;) I'm seeing a pattern here... Emile -- https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

On Saturday, September 12, 2015 at 10:38:46 PM UTC+5:30, Steven D'Aprano wrote: > On Sat, 12 Sep 2015 10:46 pm, Rustom Mody wrote: > > > On Saturday, September 12, 2015 at 11:57:01 AM UTC+5:30, Ben Finney wrote: > > >> You've clearly committed to some ontology that just doesn't match the > >>

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: Yes, Jelle, you are correct in all 3 cases. Remember that the steps are to extract the string from the source code, decode backslash escapes, and only then treat it as an f-string. For the first case, without the 'f' prefix: '{ {1: 2\N{RIGHT CURLY

Random MAC generator error

import random # global mac1 def randomMAC(): mac = [ 0x00, 0x16, 0x3e, random.randint(0x00, 0x7f), random.randint(0x00, 0xff), random.randint(0x00, 0xff) ] return ':'.join(map(lambda x: "%02x" % x, mac)) # print randomMAC() for x

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: Agreed on checking the error messages better. Especially since even the simplest of errors (like leaving out a quote) results in a syntax error in parsing the string, not parsing inside the f-string. I'll look at it eventually. --

Re: Python handles globals badly.

On 12/09/2015 17:24, Dennis Lee Bieber wrote: On Sat, 12 Sep 2015 03:35:00 +0100, Mark Lawrence declaimed the following: Ada took over from CORAL in the UK, at least in military projects. It was also used in the aircraft industry. My old work mates tell me that its

Re: Terminology: “reference” versus “pointer”

On Sat, 12 Sep 2015 02:42 pm, Random832 wrote: > Anyway, maybe we do need a term to distinguish Python/C#/Java pointers > from C/C++ pointers - maybe call it a "non-arithmetic" pointer, since > the key thing about it is you can't do pointer arithmetic on them to get > the object "next to" the one

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

> I was trying to find out how arithmetic on aware datetimes is "supposed > to" work, and tested with pytz. When I posted asking why it behaves this > way I was told that pytz doesn't behave correctly according to the way > the API was designed. You were told (by me) that its implementation of

[issue24965] Implement PEP 498: Literal String Formatting

Martin Panter added the comment: Regarding wrong error messages, I’ve learnt the hard way that it is often best to use assertRaisesRegex() instead of assertRaises(), to ensure that the actual exception you have in mind is being triggered, rather than a typo or something. Though that might

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: This one has been fixed: >>> f"{'a\\'b'}" "a'b" This one was a bug that I previously fixed, that Martin pointed out: >>> f"{x!s!s}" File "", line 1 SyntaxError: invalid character following conversion character And this is the same bug: >>> f"{x!s{y}}" File

[issue24899] Add an os.path <=> pathlib equivalence table in pathlib docs

Nikita Klimov added the comment: I make a correlation table, plan to finish by September 16 or earlier -- ___ Python tracker ___

[issue25070] Python 2.6 - Python 3.4 allows unparenthesized generator with *args, **kw, forbidden in 3.5

Roundup Robot added the comment: New changeset 10a9d4acd9cb by Yury Selivanov in branch '3.5': whatsnew/3.5 More edits https://hg.python.org/cpython/rev/10a9d4acd9cb -- nosy: +python-dev ___ Python tracker

[issue24948] Multiprocessing not timely flushing stack trace to stderr

Changes by Davin Potts : -- type: -> behavior ___ Python tracker ___ ___

[issue25070] Python 2.6 - Python 3.4 allows unparenthesized generator with *args, **kw, forbidden in 3.5

Yury Selivanov added the comment: What's new is now updated with description of this issue. Closing it now. -- resolution: -> wont fix stage: -> resolved status: open -> closed ___ Python tracker

[issue24948] Multiprocessing not timely flushing stack trace to stderr

Changes by Davin Potts : -- nosy: +jnoller, sbt ___ Python tracker ___ ___

[issue25036] IDLE - infrastructure changes so editors don't assume they're in a toplevel

Mark Roseman added the comment: FYI, I've gone past this point in my own playground, to the point of having a working tabbed editor implementation. It's not that much further actually. Here are the next steps: 1. Change so that Container is passed to Components on creation, rather than

[issue24862] subprocess.Popen behaves incorrect when moved in process tree

Changes by Andre Merzky : Removed file: http://bugs.python.org/file40448/subprocess.py.diff ___ Python tracker ___

[issue24862] subprocess.Popen behaves incorrect when moved in process tree

Changes by Andre Merzky : Added file: http://bugs.python.org/file40449/subprocess.py.diff ___ Python tracker ___

[issue25076] Wrong parameter name in distutils documentation

Roundup Robot added the comment: New changeset 1208c85af6d5 by Benjamin Peterson in branch '3.4': fix name of argument in docstring and the docs (closes #25076) https://hg.python.org/cpython/rev/1208c85af6d5 New changeset 63bbe9f80909 by Benjamin Peterson in branch '2.7': fix name of argument

Re: Terminology: "reference" versus "pointer"

On 09/12/2015 06:02 PM, Ned Batchelder wrote: > On Saturday, September 12, 2015 at 7:15:18 PM UTC-4, Mark Lawrence wrote: > [...] > But in C, pointers mean more than that. You can perform arithmetic on > them, to access memory as a linearly addressed abstraction. Python has > nothing like this.

Re: Terminology: "reference" versus "pointer"

On Saturday, September 12, 2015 at 6:25:39 PM UTC-6, ru...@yahoo.com wrote: > On 09/12/2015 05:39 PM, Rustom Mody wrote: > [...] > > which may be summarized as: > > 1. Steven (quoting Online dictionary): Pointer = Address > > 2. Steven: "Python has pointers" is ridiculous > > 3. Python docs: id

[issue25021] product_setstate() Out-of-bounds Read

Changes by Raymond Hettinger : -- resolution: -> fixed status: open -> closed ___ Python tracker ___

Re: Terminology: "reference" versus "pointer"

On 09/12/2015 05:14 PM, Mark Lawrence wrote: > On 12/09/2015 23:34, rurpy--- via Python-list wrote: >> On 09/12/2015 04:14 PM, Emile van Sebille wrote: >>> On 9/12/2015 12:58 PM, rurpy--- via Python-list wrote: >>> The question is whether what "pointer" means in languages that use the

Re: Terminology: "reference" versus "pointer"

On Sunday, September 13, 2015 at 5:32:44 AM UTC+5:30, Ned Batchelder wrote: > In its implementation, CPython uses pointers. But if you say that Python > has pointers because CPython uses pointers, then you might as well say > that Python is statically typed because the CPython source has type >

[issue25081] Windows installer Upgrade->Customize->Back goes to Install page

New submission from Steve Dower: If you already have Python 3.5.0b4 or later installed and you go to install a later version, it starts with an "Upgrade" page. If you hit customize from the page, then Back, you end up at the original Install page. You should be at the Customize page.

Re: Terminology: "reference" versus "pointer"

Rustom Mody writes: > On Saturday, September 12, 2015 at 11:57:01 AM UTC+5:30, Ben Finney wrote: > > You've clearly committed to some ontology that just doesn't match > > the Python data model. > > How about lay-English ontology in which "point to" and "refer to" are

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

On Sat, Sep 12, 2015 at 5:46 PM, Alexander Belopolsky < alexander.belopol...@gmail.com> wrote: > > On Sat, Sep 12, 2015 at 6:24 PM, Guido van Rossum > wrote: > >> The repeated claims (by Alexander?) that astimezone() has the power of >> pytz's localize() need to stop. > > >

Re: Terminology: "reference" versus "pointer"

Michael Torrie writes: > On 09/12/2015 08:22 PM, Mark Lawrence wrote: > > You appear to have the same level of knowledge of Python internals as > > the RUE has of the Python 3.3+ FSR unicode implementation. Let's have > > some fun, is Python pass by value or pass by

Re: Terminology: "reference" versus "pointer"

On Sun, 13 Sep 2015 07:10 am, Random832 wrote: > Jussi Piitulainen writes: >> I think the best way is to say that a[0] and a[1] are the same object, >> while b[0] and b[1] are different objects. > > Sure, you can *say* that. But how do you draw it on a diagram

Re: Terminology: "reference" versus "pointer"

On 09/12/2015 08:22 PM, Mark Lawrence wrote: > You appear to have the same level of knowledge of Python internals as > the RUE has of the Python 3.3+ FSR unicode implementation. Let's have > some fun, is Python pass by value or pass by reference? It has to be > more interesting debating that

Re: Terminology: "reference" versus "pointer"

On Saturday, September 12, 2015 at 10:23:24 PM UTC-4, Mark Lawrence wrote: > On 13/09/2015 01:44, rurpy--- via Python-list wrote: > > On 09/12/2015 06:02 PM, Ned Batchelder wrote: > >> On Saturday, September 12, 2015 at 7:15:18 PM UTC-4, Mark Lawrence wrote: > >> [...] > >> But in C, pointers mean

Re: Terminology: "reference" versus "pointer"

On 09/12/2015 05:39 PM, Rustom Mody wrote: > On Sunday, September 13, 2015 at 4:05:21 AM UTC+5:30, ru...@yahoo.com wrote: >> On 09/12/2015 04:14 PM, Emile van Sebille wrote: >>> On 9/12/2015 12:58 PM, rurpy--- via Python-list wrote: >>> The question is whether what "pointer" means in

Re: Terminology: "reference" versus "pointer"

On 13/09/2015 01:44, rurpy--- via Python-list wrote: On 09/12/2015 06:02 PM, Ned Batchelder wrote: On Saturday, September 12, 2015 at 7:15:18 PM UTC-4, Mark Lawrence wrote: [...] But in C, pointers mean more than that. You can perform arithmetic on them, to access memory as a linearly

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Tim] >> Me too - except I think acceptance of 495 should be contingent upon >> someone first completing a fully functional (if not releasable) >> fold-aware zoneinfo wrapping. [Alex] > Good idea. How far are you from completing that? In my head, it was done last week ;-) In real life, I'm

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: Both of those are known (to me!) byproducts of the current implementation. If my crazy idea of adding opcodes to speed up f-strings flies, then this issue will go away. I consider this a corner case that doesn't need to be addressed before committing this

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Guido] >> Those pytz methods work for any (pytz) timezone -- astimezone() with a >> default argument only works for the local time zone. {Alex] > That's what os.environ['TZ'] = zonename is for. The astimezone() method > works for every timezone installed on your system. Try it - you won't

Re: Python handles globals badly.

On 09/11/2015 11:22 PM, Skybuck Flying wrote: > I didn't learn anything from this posting, sorry ! ;) I too am not surprised. You're not here to learn, either about programming language theory, or about Python apparently. I would refer you to a good programming language theory class, but I

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Alex] >>> I will try to create a zoneinfo wrapping prototype as well, but I will >>> probably "cheat" and build it on top of pytz. [Tim] >> It would be crazy not to ;-) Note that Stuart got to punt on "the >> hard part": .utcoffset(), since pytz only uses fixed-offset classes. >> For a

[issue24965] Implement PEP 498: Literal String Formatting

Martin Panter added the comment: I’m actually trying out your patch now. A couple strange errors and observations: >>> f"{'{'}" # Why is this allowed in an outer format expression-- '{' >>> f"{3:{'{'}>10}" # --but not inside a format specifier? SyntaxError: nesting of '{' in format specifier

Re: Terminology: “reference” versus “pointer”

Mark Lawrence writes: > No it isn't. When you make a copy of an object you will end up with > two names that refer to the same object. No, when you *make a copy of* an object, you get two objects. >>> x = [1, 2, 3] >>> y = copy.copy(x) >>> x is y False What you make

Re: Python handles globals badly.

On Sat, Sep 12, 2015 at 4:25 PM, Random832 wrote: > Chris Angelico writes: >> Here. Ned Batchelder explains it better than I can. > > See, those diagrams are perfect (well, almost, I think the names should > have square boxes too). They're arrows. They

Re: Terminology: “reference” versus “pointer”

On Sat, Sep 12, 2015 at 4:26 PM, Ben Finney wrote: > If you do agree with those, some corollaries follow: > > * Container types do not contain objects. > > It is a useful analogy to say the objects are “in” the container; but > that would imply they are not

Re: Python handles globals badly.

On Sat, 12 Sep 2015 01:03 am, Ian Kelly wrote: > On Fri, Sep 11, 2015 at 2:42 AM, Steven D'Aprano > wrote: [...] >> Almost. If it's never assigned within the function, then it is looked up >> according to the non-local scoping rules: >> >> - closures and enclosing functions

  1   2   >