[issue7421] Given
New submission from Angel :
# Area calculation program
print "Show Area"
print "--"
print
# Print out the menu:
print "Please select a shape:"
print "1 Rectangle"
print "2 Circle"
# Get the user's choice:
shape = input ("> ")
# Calculate the area:
if shape == 1:
height = input ("Please enter the height: ")
width = input ("Please enter the width: ")
area = height*width
print "The area is", area
else:
radius = input ("Please enter the radius: ")
area = 3.14* (radius**2)
print "The area is", area
--
components: Windows
messages: 95871
nosy: Fallen
severity: normal
status: open
title: Given
versions: 3rd party
___
Python tracker
<http://bugs.python.org/issue7421>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3164] cPickle calls to save_string and save_unicode with unicode objects.
New submission from Angel Freire <[EMAIL PROTECTED]>: If Python trunk is compiled using Py_USING_UNICODE it'll call both, save_str and save_unicode for an string object. The patch adds a break to the case statment in case it encounters a unicode or str. -- components: Library (Lib) files: cpickle-unicode-r64448.diff keywords: patch messages: 68541 nosy: cuerty severity: normal status: open title: cPickle calls to save_string and save_unicode with unicode objects. versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file10692/cpickle-unicode-r64448.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3164> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3165] cPickle recursion problem
New submission from Angel Freire <[EMAIL PROTECTED]>:
A single Picklerobject->nesting++ will not take into consideration the
stack overhead caused by calls from
save->save_{list,dict}->batch{list,dict}.
--
components: Library (Lib)
files: cpickle-r64448.diff
keywords: patch
messages: 68544
nosy: cuerty
severity: normal
status: open
title: cPickle recursion problem
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10693/cpickle-r64448.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3165>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41350] Use of zipfile.Path causes attempt to write after ZipFile is closed
Change by Angel Siblani : -- components: +Demos and Tools, XML, email -Library (Lib) nosy: +angelsb, barry, r.david.murray type: behavior -> resource usage versions: -Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41350> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18249] Incorrect and incomplete help docs for close() method
New submission from Dave Angel:
Python 3.3.0 (default, Mar 7 2013, 00:24:38)
[GCC 4.6.3] on linux
q = open('/dev/null')
help(q.close)
the entire output is:
---
Help on built-in function close:
close(...)
(END)
---
But close() is NOT a built-in, it's a method.
(In Python 2.7.* the output is:
---
Help on built-in function close:
close(...)
close() -> None or (perhaps) an integer. Close the file.
Sets data attribute .closed to True. A closed file cannot be used for
further I/O operations. close() may be called more than once without
error. Some kinds of file objects (for example, opened by popen())
may return an exit status upon closing.
(END)
---
which is only partially wrong.
--
assignee: docs@python
components: Documentation
messages: 191382
nosy: DaveA, docs@python
priority: normal
severity: normal
status: open
title: Incorrect and incomplete help docs for close() method
___
Python tracker
<http://bugs.python.org/issue18249>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39417] Link to "Python Packaging User Guide: Creating and using virtual environments" is broken
New submission from Angel Cervera Claudio : The link "See also: Python Packaging User Guide: Creating and using virtual environments" Is broken. The problem is in line 30 of https://github.com/python/cpython/blob/3.8/Doc/library/venv.rst I don't know the right link, so I can not fix it. I any one provive me the right link, I can create a PR. -- assignee: docs@python components: Documentation messages: 360454 nosy: angelcervera, docs@python priority: normal severity: normal status: open title: Link to "Python Packaging User Guide: Creating and using virtual environments" is broken versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue39417> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39417] Link to "Python Packaging User Guide: Creating and using virtual environments" is broken
Angel Cervera Claudio added the comment: Thanks for handling this. I'm sorry I didn't have a chance to create the pr. :( On Mon 10 Feb 2020, 23:51 Carol Willing, wrote: > > Carol Willing added the comment: > > > New changeset c4a65ed7fe342bd18b5a5b0eea3470dc4fc31160 by Ogi Moore in > branch 'master': > bpo-39417: Fix broken link to guide to building venvs (GH-18432) > > https://github.com/python/cpython/commit/c4a65ed7fe342bd18b5a5b0eea3470dc4fc31160 > > > -- > nosy: +willingc > > ___ > Python tracker > <https://bugs.python.org/issue39417> > ___ > -- ___ Python tracker <https://bugs.python.org/issue39417> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34694] Dismiss To Avoid Slave/Master wording cause it easier for non English spoken programmers
New submission from Jose Angel Acosta : A request have been srecentrly uddenly committed to avoid Slave/Master wording in python code, I think the "issue"was not enough peer-reviewed, me having slave roots from my african and jewish heritage I dont consider this matter an Issue, but the Wording Slave/Master widely used to depict component relationship is better for understanding the purpose of the component relation than the non-traditional wording schemes as Parent/Worker, specially for those being non-native English readers the change has issues on code readability specially for non-English readers. Simple, its much easier to understand the meaning of Slave/Master relationship in device functionality than Worker/Helper, I consider the whole issue as an intrusion of the "politically correct" puritanism in areas where is not required. The main force behind Python success is CODE READABILITY, not political rightfulness, this should be stopped here,Python itself the language name its an word which remembers snakes a creature considered impure by both Jew/Islamic/Christian religions, by appling the same political rightfulness code to this, Python language should be renamed to something non-offensive to Jew/Islamic/Christians as Bunny, (and this at least doesnt affect language readbility, since "run bunny code" vs "run python code" its easier to understand than "Process Master delegate X Data to Slave process" vs "Parent process Delegate X Data to Worker Process", the later meaning is not as easy to understand, since Parent can be translated in N ways across different languages, I.E. Spanish: Parent could means mother, father, cause while Worker just means Worker (not intrinsically related to cause or mother). I think the python language should be kept from explicitly offensive wordings not those "niche" offensive wordings when the whole language is named after an animal that is offensive on most cultures (And its not a problem), the same naming process slave/master doesn't denote support to slavery, are just words that its more easy to understand its meaning (given its more uniform) across multiple human languages. I consider the voting mechanism should consider polls among programmers before commit matters like this in the future, which respectfully I consider ridiculous and I said it with respect to my slave ancestors. -- assignee: docs@python components: 2to3 (2.x to 3.x conversion tool), Argument Clinic, Build, Cross-Build, Demos and Tools, Distutils, Documentation, Extension Modules, FreeBSD, IDLE, IO, Installation, Interpreter Core, Library (Lib), Regular Expressions, SSL, Tests, Tkinter, Unicode, Windows, XML, asyncio, ctypes, email, macOS messages: 325434 nosy: AcostaJA, Alex.Willmer, asvetlov, barry, docs@python, dstufft, eric.araujo, ezio.melotti, koobs, larry, mrabarnett, ned.deily, paul.moore, r.david.murray, ronaldoussoren, steve.dower, terry.reedy, tim.golden, vstinner, yselivanov, zach.ware priority: normal severity: normal status: open title: Dismiss To Avoid Slave/Master wording cause it easier for non English spoken programmers type: enhancement ___ Python tracker <https://bugs.python.org/issue34694> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34694] Dismiss To Avoid Slave/Master wording cause it easier for non English spoken programmers
Jose Angel Acosta added the comment: I'm so sorry to see my proposal just derived in personal attacks. The problem here is the core who "owns" python, admited a change to the Language documentation on whats should be considered a political or cultural bias w/o considering the broad community OPINION, I wont name it irresponsible but fairly disconnected with the purpose of OpenSource: freedom as on free speech, which is something being censored by latest core's commit on suggestion based on political or cultural bias, not code usability. In other instances or communities it should have been enough to ask for the resignation of those that allowed this distortion introduced into the project -owned by the community, not the core approving commits-. -- ___ Python tracker <https://bugs.python.org/issue34694> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13896] Make shelf instances work with 'with' as context managers
Changes by Miguel Angel García : -- nosy: +Miguel.Angel.García ___ Python tracker <http://bugs.python.org/issue13896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
