Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]
Chris Angelico :
> On Sun, Jul 19, 2015 at 2:45 PM, Steven D'Aprano wrote:
>> sys.setdigits('Devanagari')
>
> Easiest way to play with this would be a sys.displayhook, I think;
I think the numeral selection is analogous to the number base:
>>> 0o10
8
>>> "{:o}".format(0o10)
'10'
what we need is:
>>> "{:d/base({base})}".format(0o10, base=7)
'11'
>>> "{:d/numeral('{num}')".format(0o10, num="European")
'8'
>>> "{:d/numeral('{num}')".format(0o10, num="Roman")
'VIII'
>>> "{:d/numeral('{num}')".format(0o10, num="RomanLowerCase")
'viii'
>>> "{:d/numeral('{num}')".format(0o10, num="EasternArabic")
'٨'
>>> "{:d/numeral('{num}')".format(0o10, num="Devanagari")
'८'
IOW, don't make it global.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]
On Sunday, July 19, 2015 at 12:46:26 PM UTC+5:30, Marko Rauhamaa wrote:
> Chris Angelico:
>
> > On Sun, Jul 19, 2015 at 2:45 PM, Steven D'Aprano wrote:
> >> sys.setdigits('Devanagari')
> >
> > Easiest way to play with this would be a sys.displayhook, I think;
>
> I think the numeral selection is analogous to the number base:
Nice analogy
>
>>>> 0o10
>8
>>>> "{:o}".format(0o10)
>'10'
>
> what we need is:
>
>>>> "{:d/base({base})}".format(0o10, base=7)
>'11'
>>>> "{:d/numeral('{num}')".format(0o10, num="European")
>'8'
>>>> "{:d/numeral('{num}')".format(0o10, num="Roman")
>'VIII'
>>>> "{:d/numeral('{num}')".format(0o10, num="RomanLowerCase")
>'viii'
>>>> "{:d/numeral('{num}')".format(0o10, num="EasternArabic")
>'٨'
>>>> "{:d/numeral('{num}')".format(0o10, num="Devanagari")
>'८'
>
> IOW, don't make it global.
But it is willy-nilly global.
Python:
>>> 4+5
9
>>>
Unix bc:
$ bc
bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
4+5
9
obase=8
4+5
11
IOW bc has two (global) variables ibase and obase for input and output base.
If you dont provide these as settable you hardwire them at 10 (8/16 in some
assembly languages)¹
Hopefully you will agree that python is more full-featured than bc and should
subsume bc functionality?
[Implementability is a second question and ease of implementability a third]
I believe numeral-language is similar
---
¹ When Ive played around with writing assemblers for toy machines, the hardwired
10-base has often been a nuisance. Of course one can in principle rebuild an
REPL.
Repurposing the existing one is usually a far more palatable option (for me).
--
https://mail.python.org/mailman/listinfo/python-list
Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]
Rustom Mody : > On Sunday, July 19, 2015 at 12:46:26 PM UTC+5:30, Marko Rauhamaa wrote: >> IOW, don't make it global. > > But it is willy-nilly global. > Python: 4+5 > 9 The interactive mode is not all that interesting, but ok, make that configurable as well. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Integers with leading zeroes
Don't be noob ? ;) Always remove leading zeroes ? One case that comes to mind is ASCII art like code... where programmer may want to align numbers for clearity: 0014324 0234545 345 0534543 ^ That could be a problem but possibly solveable with spaces instead: 14324 234545 345 534543 ^ Looks less good though in non-fixed-sized font. Bye, Skybuck. -- https://mail.python.org/mailman/listinfo/python-list
Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]
On 7/19/2015 12:45 AM, Steven D'Aprano wrote:
On Sun, 19 Jul 2015 01:52 pm, Rustom Mody wrote:
JFTR: My kids (um... students) have just managed to add devanagari
numerals to python.
ie we can now do
१ + २
3
That is actually quite awesome, and I would support a new feature that set
the numeric characters to a particular script, e.g. Latin, Arabic,
Devanagari, whatever, and printed them in that same script. It seems
unfortunate that १ + २ prints as 3 rather than ३.
Python already, and has for many years, supported non-ASCII digits in string
conversions. This is in Python 2.4:
py> int(u'१२')
12
py> float(u'.१२')
0.12
so the feature goes back a long time.
I think that Python should allow int and float literals using any sequences
of digits from the same language, e.g. 12 or १२ but not १2.
This could be done easily by adding 10 modified productions from
https://docs.python.org/3/reference/lexical_analysis.html#integer-literals
for each language. The problem of doing the above in the grammar,
including the no mixing rule, is that is *would* take a separate set of
productions for each language supported.
> One might have
an interpreter hook which displayed ints and floats using non-ASCII digits,
or one might even build that function into the intepreter, e.g. have a
global setting which tells ints and floats what digits to use, e.g.:
sys.setdigits('Devanagari')
I would support this, or something like this, as a language feature. If we
can write Python using Hindi identifiers, why not Hindi numerals?
As I remember, when non-ascii-digit inputs to int were last discussed
(python-ideas?, pydev?), the possibility of expanding literals was
mentioned. As I remember, to idea was rejected or deferred on the basis
that nearly all numbers used in production programs are read from files
as numbers or converted by int or float. The few numeric literals in
programs could just as well be converted first, or the int expression
could be used.
These true observations do not cover the shell, as in the examples
above. At some time, Guido has expresses the opinion that interactive
console python should remain plain and basic and the fancier interaction
features are the domain of replacement shells.
That brings me, anyway, to Idle. It currently imitates console python
in sending keystrokes as is to compile() and output streams as are to
the tk display. There are a couple of tracker issues claiming that this
means that Idle does not imitate console python because a tk display
does not treat backspace and return the same way simulated terminal
consoles usually do.
While the bug claims have been rejected, I have been thinking that the
Idle extension interface could and maybe should be extended so that
extensions could filter and either transform or act on the input/output
streams.
With a general mechanism in place, it would be trivial to use
str.maketrans and str.translate in the input/output streams. This would
not disable ascii digit input, including mixtures in a single literal,
but output has to all be in one digit set. Selecting a language is a
somewhat solved problem because last summer we added a extension
configuration dialog that dynamically generates a dialog tab for each
extension present.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On 7/18/2015 8:03 PM, Gary Herron wrote: On 07/18/2015 04:36 PM, Terry Reedy wrote: I would like more viewpoints from 2.7 users. I read that (incorrectly of course) and just had to ask: How do you intend to extract a viewpoint from that last 7/10 of a user? With apologies, Some humor is definitely welcome. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On 7/18/2015 11:52 PM, Rustom Mody wrote: among other things, a complaint about rejection of his desire for a mechanism for subsetting Python for teaching purposes. Response 2: Core python is the most conservatively maintained part of Python. Trying to change it radically, as distributed by PSF, is practically asking for rejection. For subsetting, I suggest a different tack: filtering input before sending it to python and raise if it contains forbidden code. After Response 1, I posted on the Devanagari thread a similar suggestion. I also posted an idea for implementing the idea by extending the internal reach of Idle extensions. I limited the idea to the interactive shell because I could not immediately think of a use for filtering code before compiling. Then I thought of this issue. Among other things, code could be tokenized or parsed to an ast for filtering. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Noob in Python. Problem with fairly simple test case
In a message of Sat, 18 Jul 2015 16:18:57 -0700, Rick Johnson writes: >I'll have to admit you make a good point here. Although the >argument is diminished by observing that Ruby is far more >popular in Asia than Python. Python seems to be mainly a >Scandinavian, European, and American toy. For the most part >anyway. There are always exceptions to any rule. I mean, >think about it: who besides Xah Lee has an Asian name here? >And it's been years since we've heard from him! O:-D This is because this is an english-speaking mailing list, not because people who don't speak English aren't using Python. Being here isn't much of an indicator. And, despite Norway not being part of the EU, Scandinavia is still in Europe. Laura -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
In a message of Sat, 18 Jul 2015 19:36:33 -0400, Terry Reedy writes: >If the vast majority of Python programmers are focused on 2.7, why are >volunteers to help fix 2.7 bugs so scarce? Because volunteers to fix any bugs are scarce? Because most people really only think of bug fixing when they have one, and when they get that one fixed they drop back into thinking that everything is perfect? >Does they all consider it perfect (or sufficient) as is? > >Should the core developers who do not personally use 2.7 stop >backporting, because no one cares if they do? > >-- >Terry Jan Reedy In the tiny corner of industrial automation where I do a lot of work, nobody is using 3.0. It is not clear that this is ever going to change. It would have to be driven by 'lack of people who know 2.x syntax' or something like that. Not 'third party library compatibility' because we really don't use them all that much. In this corner of the world, the favourite language for developing in is C (because we work close to hardware) and one of the things we like about it, a whole lot, is that the language never changes out from under you. So there is great hope among industrial users of Python that we can get a hold of a 'never going to change any more' version of Python, and then code in that 'forever' knowing that a code change isn't going to come along and break all our stuff. Bug fixes aren't supposed to do this, of course, in the same way that backporting of features do, but every so often something that was introduced to fix bug X ends up breaking something else Y. If the consequences of a bug can be 10s of thousands of Euros lost, you can see the appeal of 'this isn't going to happen any more'. While nobody likes to get bit by bugs, there is some sort of fuzzy belief out there that the bugs fixes that have gone into 2.7 are more about things that we would never run into, and thus we get the risk of change without the benefit of the bugfix. This belief isn't one that people substantiate -- it is 'just a feeling'. So from this corner of the world, which admittedly is a very small corner, yes, the news is 'Life is good. Please leave us alone.' This is in large part, I think, due to the belief that 'if things aren't breaking, things are perfect' which is completely untrue, but that's the way people are thinking. Laura -- https://mail.python.org/mailman/listinfo/python-list
Is this a good way to work with init and exception
I am using libturpial to post things on Twitter. But sometimes I get a
ServiceOverCapacity exception. So I wrote the following code.
==
class InitAlreadyDoneError(Exception):
pass
# Functions
def init(max_tries = 5, wait_time = 60):
global _core
if _core != None:
raise InitAlreadyDoneError
tries = 0
while True:
try:
_core = Core()
break
except ServiceOverCapacity:
tries += 1
sys.stderr.write('Tried to init _core it {0} times\n'.format(tries))
sys.stderr.flush()
if tries >= max_tries:
raise
time.sleep(wait_time)
==
Is this the correct way to work user defined exceptions, or should I
also define a default message?
I use this in the following way:
import twitterDecebal
twitterDecebal.init()
Because you can not give parameters with an import as far as I can
see. Is this a good way to do this, or is there a better way?
--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
--
https://mail.python.org/mailman/listinfo/python-list
batch spatial join - python
Hello, I would like to do a spatial join in a batch process in python. # I have this layers: neighbourhood = "D:\\Users\\laraifat\\Desktop\\pythonproject\\layers\\neighbourhood.shp" buildings = "D:\\Users\\laraifat\\Desktop\\pythonproject\\layers\\buildings.shp" openspace = "D:\\Users\\laraifat\\Desktop\\pythonproject\\layers\\openspace.shp" buses = "D:\\Users\\laraifat\\Desktop\\pythonproject\\layers\\buses.shp" education = "D:\\Users\\laraifat\\Desktop\\pythonproject\\layers\\education.shp" health = "D:\\Users\\laraifat\\Desktop\\pythonproject\\layers\\health.shp" sport_point_shp = "D:\\Users\\laraifat\\Desktop\\pythonproject\\layers\\sport_point.shp" #I created this variables with the layers: input_features = [sport_point_shp, health, buses, education] #the layers that will be used to count the buildings inside the neighbourhood layer new_layers = ["join_sport", "join_health", "join_buses", "join_education"] # the layer that will be created after join arcpy.BatchSpatialJoin_analysis(neighbourhood, input_features, new_layers, "JOIN_ONE_TO_ONE", "KEEP_ALL", "", "INTERSECT") but when i run the script is says: Runtime error Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'BatchSpatialJoin_analysis' How can i solve this problem? Thank you! -- https://mail.python.org/mailman/listinfo/python-list
PyQt v5.5 Released
PyQt5 v5.5 has been released and is available from http://www.riverbankcomputing.com/software/pyqt/download5. PyQt5 is a comprehensive set of bindings for v5 of The Qt Company's Qt cross-platform application framework. It supports Python v3, v2.7 and v2.6. The highlights of this release include support for Qt v5.5.0 including the new QtLocation and QtNfc modules. PyQt5 supports cross-compiling to iOS and Android. Windows installers are provided which contain everything needed for PyQt5 development (including Qt, Qt Designer, QScintilla, and MySQL, PostgreSQL, SQLite and ODBC drivers) except Python itself. Installers are provided for the 32 and 64 bit versions of Python v3.4. PyQt5 is implemented as a set of 35 extension modules comprising more than a 1,000 classes including support for: - non-GUI infrastructure including event loops, threads, i18n, user and application settings, mapped files and shared memory - GUI infrastructure including window system integration, event handling, 2D graphics, basic imaging, fonts, OpenGL - a comprehensive set of desktop widgets - WebKit and Chromium based browsers - WebSockets - location and positioning services (including OpenStreetMap) using satellite, Wi-Fi or text file sources - a client-side library for accessing Qt Cloud Services - full integration with Quick2 and QML allowing new Quick items to be implemented in Python and created in QML - event driven network programming - multimedia including cameras, audio and radios - Bluetooth - NFC enabled devices - sensors including accelerometers, altimeters, compasses, gyroscopes, magnetometers, and light, pressure, proximity, rotation and temperature sensors - serial ports - SQL - printing - DBus - XPath, XQuery, XSLT and XML Schema validation - a help system for creating and viewing searchable documentation - unit testing of GUI applications. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is this a good way to work with init and exception
Reordering/interleaving your post to respond to different parts together.
On Sun, Jul 19, 2015 at 8:35 PM, Cecil Westerhof wrote:
> I am using libturpial to post things on Twitter. But sometimes I get a
> ServiceOverCapacity exception. So I wrote the following code.
>
> ==
> class InitAlreadyDoneError(Exception):
> pass
> Is this the correct way to work user defined exceptions, or should I
> also define a default message?
I'd start by looking through the exception hierarchy for something
appropriate to subclass. In this case, you're basically saying "run
init() exactly once, and if you run it a second time, I'll throw back
an error", which probably doesn't have any logical match, so directly
subclassing Exception would be correct. But you might decide that
subclassing ValueError or RuntimeError is more appropriate.
> # Functions
> def init(max_tries = 5, wait_time = 60):
> global _core
>
> if _core != None:
> raise InitAlreadyDoneError
This is where I'd add a message, if you want one. But it looks to me
as if there's never going to be any other place that raises this, so
the message would be redundant. InitAlreadyDoneError implies "you
called init() after someone else called init()".
(Side point: It might be a neat courtesy to let people call init
again, or maybe a try_init() that won't error out if already
initialized.)
> tries = 0
> while True:
> try:
> _core = Core()
> break
> except ServiceOverCapacity:
> tries += 1
> sys.stderr.write('Tried to init _core it {0}
> times\n'.format(tries))
> sys.stderr.flush()
> if tries >= max_tries:
> raise
> time.sleep(wait_time)
> ==
>
>
> I use this in the following way:
> import twitterDecebal
> twitterDecebal.init()
>
> Because you can not give parameters with an import as far as I can
> see. Is this a good way to do this, or is there a better way?
Parameterized imports aren't possible, correct. What I'd look at here
is a more explicit instantiation. Something like:
import twitterDecebal
twitter = twitterDecebal.twitterDecebal(5, 60)
Especially since it's something that does a ton of network operations
and all sorts of sleeps and timeouts, I would strongly recommend NOT
doing this on import, even if you could. If you don't absolutely
_need_ it to be global, it'd be cleanest to make it a class that you
construct.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On 19/07/2015 03:13, Terry Reedy wrote: On 7/18/2015 7:50 PM, Devin Jeanpierre wrote: to 2.7, surely bug fixes are also allowed? Of course, allowed. But should they be made, and if so, by who? The people who want the fixes. I have contributed both performance improvements and bug fixes to 2.7. In my experience, the problem is not the lack of contributors, it's the lack of code reviewers. I understand the general problem quite well. But feeling that one would have to do a 2.7 backport after writing, editing, or reviewing a 3.x patch can discourage doing a review in the first place. I am at that point now with respect to Idle patches. Do the work with the 3.x patch and finish. Let somebody who needs the patch for 2.7 do the work. If nobody steps up to the mark that's not Terry Reedy's problem, you've done way more than your fair share over the years. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On 19/07/2015 04:45, Paul Rubin wrote: Terry Reedy writes: I am suggesting that if there are 10x as many 2.7only programmers as 3.xonly programmers, and none of the 2.7 programmers is willing to do the backport *of an already accepted patch*, then maybe it should not be done at all. The patch acceptance/approval process is frankly daunting. Correct, which is why "PEP 0462 -- Core development workflow automation for CPython" https://www.python.org/dev/peps/pep-0462/, "PEP 0474 -- Creating forge.python.org" https://www.python.org/dev/peps/pep-0474/ and a separate core-workflow mailing list exist. Admittedly things had stalled but I understand that they're being picked up again. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: batch spatial join - python
On Sun, 19 Jul 2015 10:11 pm, Lara BK wrote: > I would like to do a spatial join in a batch process in python. You seem to be using arcpy. Unfortunately, that's not a standard part of Python, so I don't know it very well. But looking at the error you get: > Traceback (most recent call last): > File "", line 1, in > AttributeError: 'module' object has no attribute > 'BatchSpatialJoin_analysis' it looks like the line starting with this: arcpy.BatchSpatialJoin_analysis(neighbourhood, blah-blah-blah...) is misspelled. Are you sure that it's called *Batch* SpacialJoin_analysis? Looking at this page: http://help.arcgis.com/en/arcgisdesktop/10.0/help/0008/0008000q00.htm I think you might need to change it to: arcpy.SpatialJoin_analysis(neighbourhood, blah-blah-blah...) Does that help? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On 19/07/2015 04:52, Rustom Mody wrote: Not to mention actively hostile attitude to discussions that could at the moment be tangential to current CPython. See (and whole thread) https://mail.python.org/pipermail/python-ideas/2015-May/033708.html This https://mail.python.org/pipermail/python-ideas/2015-May/033686.html is "actively hostile"? Sour grapes springs to my mind. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sun, 19 Jul 2015 07:27 pm, Laura Creighton wrote: > In the tiny corner of industrial automation where I do a lot of work, > nobody is using 3.0. I should hope not, because 3.0 was rubbish and is unsupported :-) I expect you mean 3.x in general. > It is not clear that this is ever going to change. > It would have to be driven by 'lack of people who know 2.x syntax' > or something like that. Not 'third party library compatibility' because > we really don't use them all that much. > > In this corner of the world, the favourite language for developing in > is C (because we work close to hardware) and one of the things we like > about it, a whole lot, is that the language never changes out from > under you. Bug for bug compatible back to the 1970s, right? :-) I sympathise, really I do. Particularly in the application space (Firefox, I'm looking at you) I'm really fed up with every security update breaking functionality, removing features, and adding anti-features. > So there is great hope among industrial users of Python > that we can get a hold of a 'never going to change any more' version > of Python, and then code in that 'forever' knowing that a code change > isn't going to come along and break all our stuff. Presumably they like the 2.7 features too much to go back to an even older version. Because 2.5 or even 1.5 are pretty stable now. I'm not kidding about 1.5, a year or two ago there was (so I'm told) a fellow at PyCon in the US who was still using 1.5. "If it ain't broke, don't fix it" -- he wasn't concerned about security updates, or new features, he just needed to keep his legacy applications running. I get it, I really do, and so do the core developers. (Well, most of them, and certainly Guido.) It cannot be said often enough and loudly enough that if you find yourself in the lucky position where you don't need to care about security updates, bug fixes or new functionality, there is absolutely nothing wrong with using an old, unmaintained, stable version forever. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On 19/07/2015 06:53, dieter wrote: Mark Lawrence writes: ... If the vast majority of Python programmers are focused on 2.7, why are volunteers to help fix 2.7 bugs so scarce? I have not done much work related to Python bug fixing. But, I had bad experience with other open source projects: many of my patches (and bug reports) have been ignored over decades. This caused me to change my attitude: I now report bugs (sometimes with patches) and publish a potential solution in a separate package (--> "dm.zopepatches.*", "dm.zodbpatches.*"). This way, affected people can use a solution even if the core developpers don't care. From my point of view: if you want help with fixing bugs, you must ensure that there is a high probability that those contributions really find their way into the main development lines. As I understand from other messages in this thread, this is also a problem with Python bug fixing. The entire workflow is the problem. This is now being addressed, see my earlier reply to Paul Rubin. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
In a message of Sun, 19 Jul 2015 23:59:29 +1000, "Steven D'Aprano" writes: >On Sun, 19 Jul 2015 07:27 pm, Laura Creighton wrote: > >> In the tiny corner of industrial automation where I do a lot of work, >> nobody is using 3.0. > >I should hope not, because 3.0 was rubbish and is unsupported :-) > >I expect you mean 3.x in general. indeed. Or should I be saying Python 3000. >Bug for bug compatible back to the 1970s, right? :-) Exactly. >> So there is great hope among industrial users of Python >> that we can get a hold of a 'never going to change any more' version >> of Python, and then code in that 'forever' knowing that a code change >> isn't going to come along and break all our stuff. > >Presumably they like the 2.7 features too much to go back to an even older >version. Because 2.5 or even 1.5 are pretty stable now. > >I'm not kidding about 1.5, a year or two ago there was (so I'm told) a >fellow at PyCon in the US who was still using 1.5. "If it ain't broke, >don't fix it" -- he wasn't concerned about security updates, or new >features, he just needed to keep his legacy applications running. I have 1.5 code out there. Unless something breaks there is no way that I will get permission to ever change it. >I get it, I really do, and so do the core developers. (Well, most of them, >and certainly Guido.) It cannot be said often enough and loudly enough that >if you find yourself in the lucky position where you don't need to care >about security updates, bug fixes or new functionality, there is absolutely >nothing wrong with using an old, unmaintained, stable version forever. Well, Terry asked. In my corner of the world -- well, iterators are cool. Though a ton of my code broke when we got a 'yield' keyword, as I had used that as a function name all over the place ... But aside from that, pretty much nothing post 1.5.2 really made a difference for us. Some bugs in struct got fixed, and that was nice, but, well on the whole we'd like stone cold dead. >-- >Steven Laura -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
In a message of Sun, 19 Jul 2015 23:59:29 +1000, "Steven D'Aprano" writes: >Bug for bug compatible back to the 1970s, right? :-) No, till the last posix in 1989 or so. Definitely not to the 1970s as we want v7 c structs and x++ not the v6 ++x version. :) Laura -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sunday, July 19, 2015 at 2:42:41 PM UTC+5:30, Terry Reedy wrote: > On 7/18/2015 11:52 PM, Rustom Mody wrote: > among other things, a complaint about rejection of his desire for a > mechanism for subsetting Python for teaching purposes. Sorry Terry if the compliant sounded louder than the answer. You asked: > If the vast majority of Python programmers are focused on 2.7, why are > volunteers to help fix 2.7 bugs so scarce? As someone who's been associated in one way or other with teaching for near 3 decades, I'd say that of the two factors which destroy an education institute -- bar to entry too high, bar to entry too low -- the second is by far the more dangerous. I believe open source is no different. If every patch is to be accepted (or even given a polite answer) there will be no remaining working code. And this will become more true the more the project is successful. Super successful projects like the linux kernel are that way because the top guys are ruthlessly meritocratic: If your submission is poor you are told "Your code is shit" If you persist, the "Your code" shortens to "You" As I said it to Paul: I am thankful that python is meritocratic As for that specific exchange I would rather not flog that horse further [in public at least -- we can continue off list] -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sun, Jul 19, 2015 at 3:27 AM, Laura Creighton wrote: > In this corner of the world, the favourite language for developing in > is C (because we work close to hardware) and one of the things we like > about it, a whole lot, is that the language never changes out from > under you. So there is great hope among industrial users of Python > that we can get a hold of a 'never going to change any more' version > of Python, and then code in that 'forever' knowing that a code change > isn't going to come along and break all our stuff. I think this is an unrealistic and unattainable goal. Even if you stop patching your Python 2.7 version altogether, what about the environment that it runs in? Are you going to stop patching the OS forever? Are you going to fix the current machine architecture exactly as it is, forever? I don't know if industrial code uses a network much or at all, but if it does, are you never going to upgrade your network infrastructure? At some point in the future, maybe far in the future, but eventually, assumptions made in the Python 2.7 code will no longer hold true, and at that point Python 2.7 will break. -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed keyword to transfer control to another function
On Mon, Jul 20, 2015 at 2:05 AM, Dennis Lee Bieber wrote: > I've only seen one other application using HHMLL -- and that was the > Amiga file system. Okay, I'll bite. What does HHMLL stand for? Google didn't answer my question instantly with the first result, like it usually does. I even got desperate [1] but no luck. ChrisA [1] https://xkcd.com/1334/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sunday 19 Jul 2015 15:42 CEST, Mark Lawrence wrote: > On 19/07/2015 03:13, Terry Reedy wrote: >> On 7/18/2015 7:50 PM, Devin Jeanpierre wrote: >>> to 2.7, surely bug fixes are also allowed? >> >> Of course, allowed. But should they be made, and if so, by who? > > The people who want the fixes. Babies want clean diapers. So babies have to change diapers themselves? -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed keyword to transfer control to another function
On 2015-07-19 17:13, Chris Angelico wrote: On Mon, Jul 20, 2015 at 2:05 AM, Dennis Lee Bieber wrote: I've only seen one other application using HHMLL -- and that was the Amiga file system. Okay, I'll bite. What does HHMLL stand for? Google didn't answer my question instantly with the first result, like it usually does. I even got desperate [1] but no luck. HHMLL stands for "hashed-head multiple-linked list", a phrase from a little earlier in the post. -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed keyword to transfer control to another function
On Mon, Jul 20, 2015 at 2:24 AM, MRAB wrote: > On 2015-07-19 17:13, Chris Angelico wrote: >> >> On Mon, Jul 20, 2015 at 2:05 AM, Dennis Lee Bieber >> wrote: >>> >>> I've only seen one other application using HHMLL -- and that was >>> the >>> Amiga file system. >> >> >> Okay, I'll bite. What does HHMLL stand for? Google didn't answer my >> question instantly with the first result, like it usually does. I even >> got desperate [1] but no luck. >> > HHMLL stands for "hashed-head multiple-linked list", a phrase from a little > earlier in the post. D'oh. I skimmed the post, looking for expressions matching that, and somehow missed it. Of course, it's right there when I go back and check again. I'm pretty sure the universe is out to gaslight me some days, particularly the days when my proposals end up indecisive. Which one of them is, today. This does not bode well. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Need assistance
On 2015-07-19 01:59, Denis McMahon wrote: On Sat, 18 Jul 2015 12:35:10 +0200, Sibylle Koczian wrote: Am 18.07.2015 um 02:40 schrieb Denis McMahon: Having a list of words, get a copy of the list in reverse order. See the reversed function (and maybe the list function). That won't really help, because the desired order is, with the example the OP used: Sirna Daniel Craig. So here indexing is necessary, but indexing of the list elements, not of the characters in the string. Oh, then it's even easier, yes, it's mainly a case of list indexing. 1) Split the original string into a list of words (string.split() method) 2) create a sublist (s1) of the last element 3) create another sublist (s2) of the first to penultimate elements 4) combine the two sublists 5) use the string.join() method to combine the sublist elements into a single string I think most pythonistas would probably combine steps 2 through 4 in a single line of code, possibly even steps 2 through 5. If you use rsplit, you can do it in one line. -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On 19/07/2015 17:10, Cecil Westerhof wrote: On Sunday 19 Jul 2015 15:42 CEST, Mark Lawrence wrote: On 19/07/2015 03:13, Terry Reedy wrote: On 7/18/2015 7:50 PM, Devin Jeanpierre wrote: to 2.7, surely bug fixes are also allowed? Of course, allowed. But should they be made, and if so, by who? The people who want the fixes. Babies want clean diapers. So babies have to change diapers themselves? That has to be the worst analogy I've ever read. We are discussing backporting working patches, *NOT* having to go through the whole shooting match from scratch. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed keyword to transfer control to another function
On 19/07/2015 17:24, MRAB wrote: On 2015-07-19 17:13, Chris Angelico wrote: On Mon, Jul 20, 2015 at 2:05 AM, Dennis Lee Bieber wrote: I've only seen one other application using HHMLL -- and that was the Amiga file system. Okay, I'll bite. What does HHMLL stand for? Google didn't answer my question instantly with the first result, like it usually does. I even got desperate [1] but no luck. HHMLL stands for "hashed-head multiple-linked list", a phrase from a little earlier in the post. I want one in the stdlib on the grounds that I like the name :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed keyword to transfer control to another function
On Mon, Jul 20, 2015 at 2:41 AM, Mark Lawrence wrote: > On 19/07/2015 17:24, MRAB wrote: >> >> On 2015-07-19 17:13, Chris Angelico wrote: >>> >>> On Mon, Jul 20, 2015 at 2:05 AM, Dennis Lee Bieber >>> wrote: I've only seen one other application using HHMLL -- and that was the Amiga file system. >>> >>> >>> Okay, I'll bite. What does HHMLL stand for? Google didn't answer my >>> question instantly with the first result, like it usually does. I even >>> got desperate [1] but no luck. >>> >> HHMLL stands for "hashed-head multiple-linked list", a phrase from a >> little >> earlier in the post. >> > > I want one in the stdlib on the grounds that I like the name :) I like the name Rachel, too, but I don't want her in the stdlib :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sunday, July 19, 2015 at 12:54:34 AM UTC-5, dieter wrote: > From my point of view: if you want help with fixing bugs, > you must ensure that there is a high probability that > those contributions really find their way into the main > development lines. As I understand from other messages in > this thread, this is also a problem with Python bug > fixing. (Not sure who said this, so my apologies if the attribution is incorrect) Bug fixing is not something most programmers find enjoyable, at least not for long durations. I prefer to spend my time solving real world problems, and designing intuitive APIs, this is what brings me joy. Heck, there have been many times that i purposefully re- invented the wheel simply because solving the problem is much easier (and more enjoyable) than trying to understand another programmer's atrocious spaghetti code. Therefor, we should not be surprised that the bug list is so understaffed and lacks vigor. What is becoming apparent to me though, is that most of the complaints i had voiced (years ago) about the exclusive attitudes, horrible interface, and the burdensome workflow of submitting patches is contributing to the lack of interest in this process -> and it seems i am not alone! I can remember twice getting excited about helping out, to only quickly become frustrated with the politics and interface. Why should i have to fight just to volunteer? What's the point? The whole system is self defeating. Time for some introspection folks. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is this a good way to work with init and exception
On Sunday 19 Jul 2015 14:59 CEST, Chris Angelico wrote: > Reordering/interleaving your post to respond to different parts > together. > > On Sun, Jul 19, 2015 at 8:35 PM, Cecil Westerhof wrote: >> I am using libturpial to post things on Twitter. But sometimes I >> get a ServiceOverCapacity exception. So I wrote the following code. >> >> == >> class InitAlreadyDoneError(Exception): pass > >> Is this the correct way to work user defined exceptions, or should >> I also define a default message? > > I'd start by looking through the exception hierarchy for something > appropriate to subclass. In this case, you're basically saying "run > init() exactly once, and if you run it a second time, I'll throw > back an error", which probably doesn't have any logical match, so > directly subclassing Exception would be correct. But you might > decide that subclassing ValueError or RuntimeError is more > appropriate. Subclassing ValueError or RuntimeError looks wrong to me. >> # Functions >> def init(max_tries = 5, wait_time = 60): >> global _core >> >> if _core != None: >> raise InitAlreadyDoneError > > This is where I'd add a message, if you want one. But it looks to me > as if there's never going to be any other place that raises this, so > the message would be redundant. InitAlreadyDoneError implies "you > called init() after someone else called init()". I thought so, but just wanted to be sure. ;-) > (Side point: It might be a neat courtesy to let people call init > again, or maybe a try_init() that won't error out if already > initialized.) I changed it to: def init(max_tries = 5, wait_time = 60, reinit_allowed = False): global _core if (_core != None) and not reinit_allowed: raise InitAlreadyDoneError >> I use this in the following way: >> import twitterDecebal >> twitterDecebal.init() >> >> Because you can not give parameters with an import as far as I can >> see. Is this a good way to do this, or is there a better way? > > Parameterized imports aren't possible, correct. What I'd look at > here is a more explicit instantiation. Something like: > > import twitterDecebal > twitter = twitterDecebal.twitterDecebal(5, 60) I worked with default values, because I thought that would be a good idea. I should remove the default values? > Especially since it's something that does a ton of network > operations and all sorts of sleeps and timeouts, I would strongly > recommend NOT doing this on import, even if you could. If you don't > absolutely _need_ it to be global, it'd be cleanest to make it a > class that you construct. In principal I only mend that before you use the twitter functions you need to do the init. (And because of the ton of functions I wanted a reinit to be an error.) In my case it is exactly below the import. Because I use it in a script and except one situation _core is always used. So I thought it to be more clear. -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof -- https://mail.python.org/mailman/listinfo/python-list
Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]
On 2015-07-19 14:45, Steven D'Aprano wrote:
>> ie we can now do
> १ + २
>> 3
>
> That is actually quite awesome, and I would support a new feature
> that set the numeric characters to a particular script, e.g. Latin,
> Arabic, Devanagari, whatever, and printed them in that same script.
> It seems unfortunate that १ + २ prints as 3 rather than ३.
>
> Python already, and has for many years, supported non-ASCII digits
> in string conversions. This is in Python 2.4:
>
> py> int(u'१२')
> 12
> py> float(u'.१२')
> 0.12
>
> so the feature goes back a long time.
Agreed that it's pretty awesome. It seems to have some holes though:
Python 3.4.2 (default, Oct 8 2014, 10:45:20)
[GCC 4.9.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> print('\N{VULGAR FRACTION ONE EIGHTH}')
⅛
>>> print(float('\N{VULGAR FRACTION ONE EIGHTH}'))
Traceback (most recent call last):
File "", line 1, in
ValueError: could not convert string to float: '⅛'
>>> print('\N{ROMAN NUMERAL NINE}')
Ⅸ
>>> int('\N{ROMAN NUMERAL NINE}')
Traceback (most recent call last):
File "", line 1, in
ValueError: invalid literal for int() with base 10: 'Ⅸ'
>>> print('\N{ROMAN NUMERAL TEN THOUSAND}')
ↂ
>>> int('\N{ROMAN NUMERAL TEN THOUSAND}')
Traceback (most recent call last):
File "", line 1, in
ValueError: invalid literal for int() with base 10: 'ↂ'
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
Re: Noob in Python. Problem with fairly simple test case
On Sunday, July 19, 2015 at 4:18:31 AM UTC-5, Laura Creighton wrote: > And, despite Norway not being part of the EU, Scandinavia > is still in Europe. This is a bit off topic: But i don't consider Scandinavia to be a part of the EU. Not anymore than i would consider America to be a part of the EU. Sure, we're all colloquially known as "the west", but large ideological and social design structures exist between the members. And besides, there is a great possibility that the EU could implode on itself. Take for instance the disaster of Greece, with many other large players teetering on the edge. The only ubiquitous binding agent between all the member countries is the existential need to conglomerate military power against foes in the east. Beyond that, the union is superficial at best. If the bailout fails, or another worldwide financial crisis hits, the outcome could be disastrous for the EU. When those pension checks stop coming in the mail, people get violent! -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sunday 19 Jul 2015 18:38 CEST, Mark Lawrence wrote: > On 19/07/2015 17:10, Cecil Westerhof wrote: >> On Sunday 19 Jul 2015 15:42 CEST, Mark Lawrence wrote: >> >>> On 19/07/2015 03:13, Terry Reedy wrote: On 7/18/2015 7:50 PM, Devin Jeanpierre wrote: > to 2.7, surely bug fixes are also allowed? Of course, allowed. But should they be made, and if so, by who? >>> >>> The people who want the fixes. >> >> Babies want clean diapers. So babies have to change diapers >> themselves? >> > > That has to be the worst analogy I've ever read. We are discussing > backporting working patches, *NOT* having to go through the whole > shooting match from scratch. You think so? I think that a lot of people who are using 2.7 would like to have the fixes. They know how to use Python, but they would not now how to implement a patch. That is why I made this comment. Comments are (almost) always an exaggeration. When someone tells me: “I have been 1.000 times to the store to get my money back”, most of the time I would not take this literally, but understand it means very often. -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof -- https://mail.python.org/mailman/listinfo/python-list
Re: Noob in Python. Problem with fairly simple test case
On 2015-07-19 18:25, Rick Johnson wrote: On Sunday, July 19, 2015 at 4:18:31 AM UTC-5, Laura Creighton wrote: And, despite Norway not being part of the EU, Scandinavia is still in Europe. This is a bit off topic: But i don't consider Scandinavia to be a part of the EU. Not anymore than i would consider America to be a part of the EU. Sure, we're all colloquially known as "the west", but large ideological and social design structures exist between the members. And besides, there is a great possibility that the EU could implode on itself. [snip] Denmark and Sweden are _both_ members of the EU. -- https://mail.python.org/mailman/listinfo/python-list
Re: Noob in Python. Problem with fairly simple test case
In a message of Sun, 19 Jul 2015 10:25:35 -0700, Rick Johnson writes: >On Sunday, July 19, 2015 at 4:18:31 AM UTC-5, Laura Creighton wrote: >> And, despite Norway not being part of the EU, Scandinavia >> is still in Europe. > >This is a bit off topic: But i don't consider Scandinavia to >be a part of the EU. Not anymore than i would consider >America to be a part of the EU. Well, that makes one of you. The significant number of people who want to pull Sweden out of the EU still have a lot of work ahead of them before ignoring laws that come from Brussels is in my future. But in or out of the EU, Sweden will still be in Europe. Laura -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On 19/07/2015 18:14, Cecil Westerhof wrote: On Sunday 19 Jul 2015 18:38 CEST, Mark Lawrence wrote: On 19/07/2015 17:10, Cecil Westerhof wrote: On Sunday 19 Jul 2015 15:42 CEST, Mark Lawrence wrote: On 19/07/2015 03:13, Terry Reedy wrote: On 7/18/2015 7:50 PM, Devin Jeanpierre wrote: to 2.7, surely bug fixes are also allowed? Of course, allowed. But should they be made, and if so, by who? The people who want the fixes. Babies want clean diapers. So babies have to change diapers themselves? That has to be the worst analogy I've ever read. We are discussing backporting working patches, *NOT* having to go through the whole shooting match from scratch. You think so? I think that a lot of people who are using 2.7 would like to have the fixes. They know how to use Python, but they would not now how to implement a patch. That is why I made this comment. I don't think so, I know. If they want the patches that badly and can't do it themselves they'll have to grin and bear it, or do a bit of begging, or pay somebody to do it for them. Unless the PSF or another body does the paying, something which I vaguely recall hearing about. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]
On Sun, Jul 19, 2015 at 10:56 PM, Tim Chase
wrote:
> Agreed that it's pretty awesome. It seems to have some holes though:
>
> Python 3.4.2 (default, Oct 8 2014, 10:45:20)
> [GCC 4.9.1] on linux
> Type "help", "copyright", "credits" or "license" for more information.
print('\N{VULGAR FRACTION ONE EIGHTH}')
> ⅛
print(float('\N{VULGAR FRACTION ONE EIGHTH}'))
> Traceback (most recent call last):
> File "", line 1, in
> ValueError: could not convert string to float: '⅛'
print('\N{ROMAN NUMERAL NINE}')
> Ⅸ
int('\N{ROMAN NUMERAL NINE}')
> Traceback (most recent call last):
> File "", line 1, in
> ValueError: invalid literal for int() with base 10: 'Ⅸ'
print('\N{ROMAN NUMERAL TEN THOUSAND}')
> ↂ
int('\N{ROMAN NUMERAL TEN THOUSAND}')
> Traceback (most recent call last):
> File "", line 1, in
> ValueError: invalid literal for int() with base 10: 'ↂ'
The int() and float() functions accept, if I'm not mistaken, anything
with Unicode category "Nd" (Number, decimal digit). In your examples,
the fraction (U+215B) is No, and the Roman numerals (U+2168, U+2182)
are Nl, so they're not supported. Adding support for these forms might
be accepted as a feature request, but it's not a bug.
(I may be wrong about the definition being based on category. It may
be based on the "Numeric type" of each character. But again, the
characters that are accepted would be those which have a Digit type,
not merely Numeric, and again, it'd be a feature request to expand
that.)
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
flipping string order
On Sun, 19 Jul 2015 17:35:03 +0100, MRAB wrote:
> rsplit -> one line.
def lastWordFirst(s):
return " ".join(reversed(s.rsplit(" ", 1)))
--
Denis McMahon, [email protected]
--
https://mail.python.org/mailman/listinfo/python-list
Re: Is this a good way to work with init and exception
On Mon, Jul 20, 2015 at 2:46 AM, Cecil Westerhof wrote: > On Sunday 19 Jul 2015 14:59 CEST, Chris Angelico wrote: > >> Reordering/interleaving your post to respond to different parts >> together. >> >> On Sun, Jul 19, 2015 at 8:35 PM, Cecil Westerhof wrote: >>> I am using libturpial to post things on Twitter. But sometimes I >>> get a ServiceOverCapacity exception. So I wrote the following code. >>> >>> == >>> class InitAlreadyDoneError(Exception): pass >> >>> Is this the correct way to work user defined exceptions, or should >>> I also define a default message? >> >> I'd start by looking through the exception hierarchy for something >> appropriate to subclass. In this case, you're basically saying "run >> init() exactly once, and if you run it a second time, I'll throw >> back an error", which probably doesn't have any logical match, so >> directly subclassing Exception would be correct. But you might >> decide that subclassing ValueError or RuntimeError is more >> appropriate. > > Subclassing ValueError or RuntimeError looks wrong to me. Sure. Like I said, directly subclassing Exception seemed the most logical route. Just threw that out there as a possibility. >> (Side point: It might be a neat courtesy to let people call init >> again, or maybe a try_init() that won't error out if already >> initialized.) > > I changed it to: > > def init(max_tries = 5, wait_time = 60, reinit_allowed = False): > global _core > > if (_core != None) and not reinit_allowed: > raise InitAlreadyDoneError > That works, too! >>> I use this in the following way: >>> import twitterDecebal >>> twitterDecebal.init() >>> >>> Because you can not give parameters with an import as far as I can >>> see. Is this a good way to do this, or is there a better way? >> >> Parameterized imports aren't possible, correct. What I'd look at >> here is a more explicit instantiation. Something like: >> >> import twitterDecebal >> twitter = twitterDecebal.twitterDecebal(5, 60) > > I worked with default values, because I thought that would be a good > idea. I should remove the default values? No no, the default values are good. I just gave an example that didn't use them, as that's where you actually need the call. If you're always going to use the defaults, well, there's not a lot of point having the function. But if you often use the defaults (or one of them), and occasionally override it, then what you have is good design. >> Especially since it's something that does a ton of network >> operations and all sorts of sleeps and timeouts, I would strongly >> recommend NOT doing this on import, even if you could. If you don't >> absolutely _need_ it to be global, it'd be cleanest to make it a >> class that you construct. > > In principal I only mend that before you use the twitter functions you > need to do the init. (And because of the ton of functions I wanted a > reinit to be an error.) In my case it is exactly below the import. > Because I use it in a script and except one situation _core is always > used. So I thought it to be more clear. I think it's fine, then. As long as it makes absolutely no sense to have two separately-initialized twitter connections, and as long as it's okay for two separate modules to both import this and to then share state, then what you have is fine. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
In a message of Sun, 19 Jul 2015 09:29:11 -0600, Ian Kelly writes: >I think this is an unrealistic and unattainable goal. Even if you stop >patching your Python 2.7 version altogether, what about the >environment that it runs in? Are you going to stop patching the OS >forever? Are you going to fix the current machine architecture exactly >as it is, forever? I don't know if industrial code uses a network much >or at all, but if it does, are you never going to upgrade your network >infrastructure? There is clearly some wishful thinking going around here, but in terms of having the same machine architecture forever ... well, my friend the hardware guy can make you a board that you can plug your old perfectly working, reliable 1970s tech machines into -- because they really want to be plugged into a pdp-11 running RSX-11. Then we fake things using Python to simulate enough RSX-11 to keep on running. We figure the machines will still be running long after we are dead. Laura -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Mon, Jul 20, 2015 at 4:14 AM, Laura Creighton wrote: > In a message of Sun, 19 Jul 2015 09:29:11 -0600, Ian Kelly writes: >>I think this is an unrealistic and unattainable goal. Even if you stop >>patching your Python 2.7 version altogether, what about the >>environment that it runs in? Are you going to stop patching the OS >>forever? Are you going to fix the current machine architecture exactly >>as it is, forever? I don't know if industrial code uses a network much >>or at all, but if it does, are you never going to upgrade your network >>infrastructure? > > There is clearly some wishful thinking going around here, but > in terms of having the same machine architecture forever ... well, my > friend the hardware guy can make you a board that you can plug your > old perfectly working, reliable 1970s tech machines into -- because they > really want to be plugged into a pdp-11 running RSX-11. Then we fake > things using Python to simulate enough RSX-11 to keep on running. > > We figure the machines will still be running long after we are dead. And for software, you can often run emulators. How many people have ancient Amiga games running on modern PCs via some sort of emulation layer? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sunday, July 19, 2015 at 12:55:06 PM UTC-5, Mark Lawrence wrote: > I don't think so, I know. If they want the patches that > badly and can't do it themselves they'll have to grin and > bear it, or do a bit of begging, or pay somebody to do it > for them. It's all about the effing money then? So the barriers are not a bug, but a feature? Mr. Gates would be *SO* proud! -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sunday, July 19, 2015 at 7:28:15 PM UTC+1, Rick Johnson wrote: > On Sunday, July 19, 2015 at 12:55:06 PM UTC-5, Mark Lawrence wrote: > > I don't think so, I know. If they want the patches that > > badly and can't do it themselves they'll have to grin and > > bear it, or do a bit of begging, or pay somebody to do it > > for them. > > It's all about the effing money then? So the barriers are not a > bug, but a feature? Mr. Gates would be *SO* proud! No, it's simply that nobody can force volunteers to back port something when they're just not interested in doing the work, for whatever reason. Hence my statement above, of which you have focussed on the last eight words. -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sun, Jul 19, 2015 at 10:10 AM, Cecil Westerhof wrote: > On Sunday 19 Jul 2015 15:42 CEST, Mark Lawrence wrote: > >> On 19/07/2015 03:13, Terry Reedy wrote: >>> On 7/18/2015 7:50 PM, Devin Jeanpierre wrote: to 2.7, surely bug fixes are also allowed? >>> >>> Of course, allowed. But should they be made, and if so, by who? >> >> The people who want the fixes. > > Babies want clean diapers. So babies have to change diapers > themselves? Poor analogy. Babies need others to change their diapers for them because they're not capable of doing it for themselves. -- https://mail.python.org/mailman/listinfo/python-list
how to play
i have trouble trying to play python please can you respond soon -- https://mail.python.org/mailman/listinfo/python-list
Re: how to play
On Sun, Jul 19, 2015 at 1:01 PM, Aron Barsam wrote: > i have trouble trying to play python please can you respond soon "Play" is an odd choice of verb. Are you under the impression that Python is a game? Anyway, here's how to use Python: 1. Download Python from python.org. 2. Install Python on your local system. 3. Start Python from your OS command line. 4. ? 5. Profit! If you can tell us in more detail which step it is that you're stuck on and what problem you're running into, then maybe we can help. -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sunday, July 19, 2015 at 1:44:25 PM UTC-5, [email protected] wrote: > No, it's simply that nobody can force volunteers to back > port something when they're just not interested in doing > the work, for whatever reason. Hence my statement above, > of which you have focused on the last eight words. Well i argue that the free labor *WOULD* exists *IF* the patching mechanism were more inclusive and intuitive. PS: My apologies to Mark Lawrence for mis-attributing the quote to him. I seem to be having a bad quote day. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is this a good way to work with init and exception
On Sunday 19 Jul 2015 20:11 CEST, Chris Angelico wrote: >>> Parameterized imports aren't possible, correct. What I'd look at >>> here is a more explicit instantiation. Something like: >>> >>> import twitterDecebal >>> twitter = twitterDecebal.twitterDecebal(5, 60) >> >> I worked with default values, because I thought that would be a >> good idea. I should remove the default values? > > No no, the default values are good. I just gave an example that > didn't use them, as that's where you actually need the call. If > you're always going to use the defaults, well, there's not a lot of > point having the function. But if you often use the defaults (or one > of them), and occasionally override it, then what you have is good > design. In my case I think the defaults are good. (But I do not know how I will use the function in the future. ;-) ) But I want to share it on GitHub and it would be possible that for someone else my defaults are not correct and then it is nice when they can be overridden. > I think it's fine, then. As long as it makes absolutely no sense to > have two separately-initialized twitter connections, and as long as > it's okay for two separate modules to both import this and to then > share state, then what you have is fine. I do not see myself doing this, but I like to know ‘everything’. When I have a program with two different modules that both import this, they would get in each-others way? How? -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof -- https://mail.python.org/mailman/listinfo/python-list
Re: how to play
On 2015-07-19 20:01, Aron Barsam wrote: i have trouble trying to play python please can you respond soon You'll need to provide some details. Saying "i have trouble" isn't helpful. Help us to help you. Which operating system are you using? Windows, MacOS, Linux? Which version? Which version of Python? What are you doing? If there's an error message, what does it say? -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sunday, July 19, 2015 at 2:02:12 PM UTC-5, Ian wrote: > Poor analogy. Babies need others to change their diapers > for them because they're not capable of doing it for > themselves. Duh! That was the point of his analogy, Ian. *ALL* Python programmers need the patches. Whether or not they possess the skill to create them is irrelevant. But the baby is not the only victim if the diapers are not changed. Imagine the foul odors that "rumors of bugginess" will emit into the household, and if unchecked long enough, out into the neighborhood. A some point a social worker will be dispatched, and the baby will be taken away to a home that provides the necessary sanitary conditions. But not before the parents will be thrown in prison, ridiculed, and forgotten. The end result is a broken family Ian. Is any of this sinking in? -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On 7/18/2015 10:33 PM, Devin Jeanpierre wrote: On Sat, Jul 18, 2015 at 6:34 PM, Terry Reedy wrote: On 7/18/2015 8:27 PM, Mark Lawrence wrote: On 19/07/2015 00:36, Terry Reedy wrote: Programmers don't much like doing maintainance work when they're paid to do it, so why would they volunteer to do it? Right. So I am asking: if a 3.x user volunteers a 3.x patch and a 3.x core developer reviews and edits the patch until it is ready to commit, why should either of them volunteer to do a 2.7 backport that they will not use? Because it helps even more people. Writing another 3.x patch would also help other people and might be more 'fun'. That is the situation I am in with respect to Idle. It gets really boring submitting 2.7-specific patches, though, when they aren't accepted, and the committers have such a hostile attitude towards it. I was told by core devs that, instead of fixing bugs in Python 2, I should just rewrite my app in Python 3. It has even been implied that bugs in Python 2 are *good*, because that might help with Python 3 adoption. Like Steven, I would be interested in specifics, though I do not disbelieve you. I do not believe those two attitudes are exactly official policy, and I may request more discussion of them on pydev. Then even if you do the work to fix *ANY* bug there is no guarantee that it gets committed. I am discussing the situation where there *is* a near guarantee (if the backport works and does not break anything and has not been so heavily revised as to require a separate review). That is not how I have experienced contribution to CPython. I know. Some core developers are trying to revamp the issue-patch handling process to remove some of the busywork, use our time more efficiency, and make it work more smoothly for everyone. But let me try again. I am discussing a situation where a core developer has either requested or already agreed to apply a 2.7 backport. I have seen such in the past, but maybe this is now rare. I specifically would like to be able to request backports for Idle patches and get responses. When requested, I really would apply responses that worked. Really. But I now realized that most people would rather write a patch, on their own schedule, for an issue that bugs them, and perhaps use it locally, even if rejected for the repository, than write a guaranteed patch 'right now for a issue of no interest to them (and which might require python knowledge they do not have). If the issue was closed as fixed before I contributed the backported patch, does anyone even see it? Yes. All changes on as issue, including uploads, are emailed to all on the nosy list regardless of open/closed/... status. However, I would inquire first. "If I backport the committed bugfix to 2.7, would you apply it?" -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Integers with leading zeroes
On Sunday, July 19, 2015 at 3:19:01 AM UTC-5, Skybuck Flying wrote: > 14324 > 234545 > 345 > 534543 > > ^ Looks less good though in non-fixed-sized font. The obvious solution is to use a fixed width font. If you're inserting syntactical noise simply to maintain readability in variable width fonts, then you may want to reconsider the practicality of such a font. Readability counts. And errors (even mental errors) should never pass silently. -- https://mail.python.org/mailman/listinfo/python-list
Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]
On 2015-07-20 04:07, Chris Angelico wrote: > The int() and float() functions accept, if I'm not mistaken, > anything with Unicode category "Nd" (Number, decimal digit). In > your examples, the fraction (U+215B) is No, and the Roman numerals > (U+2168, U+2182) are Nl, so they're not supported. Adding support > for these forms might be accepted as a feature request, but it's > not a bug. Ah, that makes sense. Some simple testing (thanks, unicodedata module) supports your conjecture. It's not a particularly big deal so not really worth the brain-cycles to add support for them. Just upon hearing "Python's int() does smart things with Unicode characters", those were some of my first characters to try. The failure struck me as odd until you explained the simple difference. -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sunday 19 Jul 2015 21:01 CEST, Ian Kelly wrote: > On Sun, Jul 19, 2015 at 10:10 AM, Cecil Westerhof wrote: >> On Sunday 19 Jul 2015 15:42 CEST, Mark Lawrence wrote: >> >>> On 19/07/2015 03:13, Terry Reedy wrote: On 7/18/2015 7:50 PM, Devin Jeanpierre wrote: > to 2.7, surely bug fixes are also allowed? Of course, allowed. But should they be made, and if so, by who? >>> >>> The people who want the fixes. >> >> Babies want clean diapers. So babies have to change diapers >> themselves? > > Poor analogy. Babies need others to change their diapers for them > because they're not capable of doing it for themselves. That is why I think it is good analogy. I think that most of the users of 2.7 who would be delighted with fixes would have no idea how to get those fixes into 2.7. -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sunday, July 19, 2015 at 8:13:50 PM UTC+1, Rick Johnson wrote: > On Sunday, July 19, 2015 at 1:44:25 PM UTC-5, [email protected] wrote: > > No, it's simply that nobody can force volunteers to back > > port something when they're just not interested in doing > > the work, for whatever reason. Hence my statement above, > > of which you have focused on the last eight words. > > Well i argue that the free labor *WOULD* exists *IF* the > patching mechanism were more inclusive and intuitive. > "More inclusive"? Any man and his dog can get an account on the issue tracker? Perhaps it isn't "intuitive", but then reading the development guide tends to help. All in all though I have to admit that overall it's a really onerous task. Once you've produced the patch you have to go to all the trouble of logging on to the issue tracker, finding the appropriate issue and uploading the patch. You may even be inclined to make a comment. In this case this entire process could take as much as two whole minutes. -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On 19/07/2015 21:05, Cecil Westerhof wrote: On Sunday 19 Jul 2015 21:01 CEST, Ian Kelly wrote: On Sun, Jul 19, 2015 at 10:10 AM, Cecil Westerhof wrote: On Sunday 19 Jul 2015 15:42 CEST, Mark Lawrence wrote: On 19/07/2015 03:13, Terry Reedy wrote: On 7/18/2015 7:50 PM, Devin Jeanpierre wrote: to 2.7, surely bug fixes are also allowed? Of course, allowed. But should they be made, and if so, by who? The people who want the fixes. Babies want clean diapers. So babies have to change diapers themselves? Poor analogy. Babies need others to change their diapers for them because they're not capable of doing it for themselves. That is why I think it is good analogy. I think that most of the users of 2.7 who would be delighted with fixes would have no idea how to get those fixes into 2.7. They could try reading the development guide to start with, or is that also too much to ask? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sunday, July 19, 2015 at 8:29:06 PM UTC+1, Rick Johnson wrote: > On Sunday, July 19, 2015 at 2:02:12 PM UTC-5, Ian wrote: > > Poor analogy. Babies need others to change their diapers > > for them because they're not capable of doing it for > > themselves. > > Duh! That was the point of his analogy, Ian. *ALL* Python > programmers need the patches. Whether or not they possess > the skill to create them is irrelevant. > Wrong, not all programmers need the patches as a lot of people couldn't care two hoots about 2.7. I'm one of them. If a programmer can't create a patch then they're in the wrong job. > But the baby is not the only victim if the diapers are not > changed. Imagine the foul odors that "rumors of bugginess" > will emit into the household, and if unchecked long enough, > out into the neighborhood. > > A some point a social worker will be dispatched, and the > baby will be taken away to a home that provides the > necessary sanitary conditions. But not before the parents > will be thrown in prison, ridiculed, and forgotten. The end > result is a broken family Ian. > > Is any of this sinking in? No because as always it's complete dross. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is this a good way to work with init and exception
On Mon, Jul 20, 2015 at 5:10 AM, Cecil Westerhof wrote: >> I think it's fine, then. As long as it makes absolutely no sense to >> have two separately-initialized twitter connections, and as long as >> it's okay for two separate modules to both import this and to then >> share state, then what you have is fine. > > I do not see myself doing this, but I like to know ‘everything’. When > I have a program with two different modules that both import this, > they would get in each-others way? How? If two modules import the same module, they get two references to that same module, not two separate module instances. Since your parameters appear only to affect the initialization itself, this is not likely to be a problem (it's not like you'll need to authenticate with two different sets of credentials, for instance), but it will mean that the second one will import an already-initialized module. That's why I suggested the try_init function which would quietly return an immediate success if the module had already been initialized. But if this isn't going to be an issue, then your code's fine. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]
On Mon, Jul 20, 2015 at 5:55 AM, Tim Chase
wrote:
> On 2015-07-20 04:07, Chris Angelico wrote:
>> The int() and float() functions accept, if I'm not mistaken,
>> anything with Unicode category "Nd" (Number, decimal digit). In
>> your examples, the fraction (U+215B) is No, and the Roman numerals
>> (U+2168, U+2182) are Nl, so they're not supported. Adding support
>> for these forms might be accepted as a feature request, but it's
>> not a bug.
>
> Ah, that makes sense. Some simple testing (thanks, unicodedata
> module) supports your conjecture.
>
> It's not a particularly big deal so not really worth the brain-cycles
> to add support for them. Just upon hearing "Python's int() does
> smart things with Unicode characters", those were some of my first
> characters to try. The failure struck me as odd until you explained
> the simple difference.
The other part of the problem is: What should float("2⅛3") be? Should
it be equal to 21.0/83.0? Should the first part be parsed as a classic
mixed number (2 + 1/8), and then what should the 3 mean? While it's
easy to see what an individual character should represent (just check
unicodedata.numeric(ch) - for ⅛ it's 0.125), the true meaning of a
string of such characters is less than clear. Similarly, Roman
numerals aren't meant to be used after the decimal point, so "Ⅸ.Ⅴ"
does not normally mean nine and a half... not to mention the confusing
situation that "ⅠⅤ" would naively parse as 15 but "Ⅳ" is definitely 4.
Since these kinds of complexities exist, it's safest to reserve this
level of parsing for a special-purpose function. If someone can come
up with a really strong argument for the float() and int()
constructors interpreting these, I'd expect to see it deployed as a
third-party module first, before being pointed out as "see, you can
use float() for all these, but if you want to use those, you should
use Float() instead". (Incidentally, I fully expect to see, some day,
pytz.localize() semantics brought into the standard library
datetime.datetime class, for precisely this reason.)
Unicode is awesome, but it's not a panacea :)
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On 7/19/2015 5:27 AM, Laura Creighton wrote: In a message of Sat, 18 Jul 2015 19:36:33 -0400, Terry Reedy writes: If the vast majority of Python programmers are focused on 2.7, why are volunteers to help fix 2.7 bugs so scarce? Because volunteers to fix any bugs are scarce? Because most people really only think of bug fixing when they have one, and when they get that one fixed they drop back into thinking that everything is perfect? Does they all consider it perfect (or sufficient) as is? Should the core developers who do not personally use 2.7 stop backporting, because no one cares if they do? -- Terry Jan Reedy In the tiny corner of industrial automation where I do a lot of work, nobody is using 3.0. It is not clear that this is ever going to change. It would have to be driven by 'lack of people who know 2.x syntax' or something like that. Not 'third party library compatibility' because we really don't use them all that much. In this corner of the world, the favourite language for developing in is C (because we work close to hardware) and one of the things we like about it, a whole lot, is that the language never changes out from under you. So there is great hope among industrial users of Python that we can get a hold of a 'never going to change any more' version of Python, and then code in that 'forever' knowing that a code change isn't going to come along and break all our stuff. Any version of Python too old even for security patches would qualify. Of course, in a chaotic environment, static code may mean unstatic behavior. Changing internet attacks and changing build environments are the prime reason for extending 2.7 maintenance. Bug fixes aren't supposed to do this, of course, in the same way that backporting of features do, but every so often something that was introduced to fix bug X ends up breaking something else Y. If the consequences of a bug can be 10s of thousands of Euros lost, you can see the appeal of 'this isn't going to happen any more'. While nobody likes to get bit by bugs, there is some sort of fuzzy belief out there that the bugs fixes that have gone into 2.7 are more about things that we would never run into, and thus we get the risk of change without the benefit of the bugfix. This belief isn't one that people substantiate -- it is 'just a feeling'. So from this corner of the world, which admittedly is a very small corner, yes, the news is 'Life is good. Please leave us alone.' This is in large part, I think, due to the belief that 'if things aren't breaking, things are perfect' which is completely untrue, but that's the way people are thinking. The extended extended maintenance for 2.7 (from now to 2020) is primarily for security and build fixes. I am beginning to think that the ambiguity of 'secondarily for other fixes, on a case-by-case basis, as determined by the whim of individual core developers' is a disservice to most users as well as most core developers. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sunday, July 19, 2015 at 3:36:21 PM UTC-5, [email protected] wrote: > Wrong, not all programmers need the patches as a lot of > people couldn't care two hoots about 2.7. Well you should. Because apparently, you're incapable of recognizing that Py2 and Py3 are existentially joined at the hip! The world of language survival is more complex than your selfish desires. If you're unable to draw parallels between py2 and py3, it's only because your focused is far too narrow. Negative perception of py2 translates to negative perception of py3. Python is the sum of all it's parts. Not merely the small part (or rattle) that you happen to find amusing. And since py3 is the smallest part of Python, and py2 is the largest, you would be wise to consider the consequences of a failed, or even perceived failure, of Py2. If you change the diapers in Py3 nursery but refuse to change them in Py2 nursery, you might alleviate the your diaper rash, but other babies poop will always smell worse than your own! -- https://mail.python.org/mailman/listinfo/python-list
Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]
On 2015-07-19 22:16, Chris Angelico wrote:
On Mon, Jul 20, 2015 at 5:55 AM, Tim Chase
wrote:
On 2015-07-20 04:07, Chris Angelico wrote:
The int() and float() functions accept, if I'm not mistaken,
anything with Unicode category "Nd" (Number, decimal digit). In
your examples, the fraction (U+215B) is No, and the Roman numerals
(U+2168, U+2182) are Nl, so they're not supported. Adding support
for these forms might be accepted as a feature request, but it's
not a bug.
Ah, that makes sense. Some simple testing (thanks, unicodedata
module) supports your conjecture.
It's not a particularly big deal so not really worth the brain-cycles
to add support for them. Just upon hearing "Python's int() does
smart things with Unicode characters", those were some of my first
characters to try. The failure struck me as odd until you explained
the simple difference.
The other part of the problem is: What should float("2⅛3") be? Should
it be equal to 21.0/83.0? Should the first part be parsed as a classic
mixed number (2 + 1/8), and then what should the 3 mean? While it's
easy to see what an individual character should represent (just check
unicodedata.numeric(ch) - for ⅛ it's 0.125), the true meaning of a
string of such characters is less than clear. Similarly, Roman
numerals aren't meant to be used after the decimal point, so "Ⅸ.Ⅴ"
does not normally mean nine and a half... not to mention the confusing
situation that "ⅠⅤ" would naively parse as 15 but "Ⅳ" is definitely 4.
Since these kinds of complexities exist, it's safest to reserve this
level of parsing for a special-purpose function. If someone can come
up with a really strong argument for the float() and int()
constructors interpreting these, I'd expect to see it deployed as a
third-party module first, before being pointed out as "see, you can
use float() for all these, but if you want to use those, you should
use Float() instead". (Incidentally, I fully expect to see, some day,
pytz.localize() semantics brought into the standard library
datetime.datetime class, for precisely this reason.)
Unicode is awesome, but it's not a panacea :)
What's the result of, say, float('1e.3')?
It raises an exception.
So float("2⅛3") should also raise an exception.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On 7/18/2015 10:48 PM, Zachary Ware wrote: On Sat, Jul 18, 2015 at 9:13 PM, Terry Reedy wrote: I understand the general problem quite well. But feeling that one would have to do a 2.7 backport after writing, editing, or reviewing a 3.x patch can discourage doing a review in the first place. I am at that point now with respect to Idle patches. I wonder if it would be worth the significant one-time effort to port IDLE to 2/3, so that future bugfixes/improvements don't require any extra effort than testing them with all versions. I am not aware of any version problems with tkinter code. In general, in the modules I have looked at, the main necessary differences are the Tkinter/tkinter, MessageBox/messagebox imports. In some files, the exception changes in 3.3 are even more a nuisance, since the name differences can be anywhere in the file. Since 2.7 patching will end sooner or later, I am reluctant to add 'if version' to 3.x. The exception changes could be masked in 2.7 by rebinding exception names at the top, but I am not sure that this would be a good idea. I, and others, have already made some changes to eliminate differences that are unnecessary, at least for 2.7 versus 3.3+ or now 3.4+. For instance, I believe all 'except X, msg:' statements have been converted to 'except X as msg:'. Most of the files with 'print' still need conversion to a future imports + function call. I have eliminated most other differences in at least a couple of modules before patching, and in one module that needs multiple patches. Hmm. After manual insertion of future print imports in 2.7 files, 2to3 could be used to convert the 2.7 print statements. This would be much easier than manual conversion and or copying for 3.x. Thanks for the inspiration. https://bugs.python.org/issue24671 -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Is this a good way to work with init and exception
On Sunday 19 Jul 2015 23:08 CEST, Chris Angelico wrote: > On Mon, Jul 20, 2015 at 5:10 AM, Cecil Westerhof wrote: >>> I think it's fine, then. As long as it makes absolutely no sense >>> to have two separately-initialized twitter connections, and as >>> long as it's okay for two separate modules to both import this and >>> to then share state, then what you have is fine. >> >> I do not see myself doing this, but I like to know ‘everything’. >> When I have a program with two different modules that both import >> this, they would get in each-others way? How? > > If two modules import the same module, they get two references to > that same module, not two separate module instances. Since your > parameters appear only to affect the initialization itself, this is > not likely to be a problem (it's not like you'll need to > authenticate with two different sets of credentials, for instance), > but it will mean that the second one will import an > already-initialized module. That's why I suggested the try_init > function which would quietly return an immediate success if the > module had already been initialized. But if this isn't going to be > an issue, then your code's fine. Good to know. I would expect two different instances. I agree that in my case it would not be a problem, but I put the code on GitHub: https://github.com/CecilWesterhof/PythonLibrary/blob/master/twitterDecebal.py I should do my best to circumvent nasty surprises for users of the code. Someone else could use several Twitter accounts at the same time. Is there a way to do this? -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sunday 19 Jul 2015 22:28 CEST, Mark Lawrence wrote: > On 19/07/2015 21:05, Cecil Westerhof wrote: >> On Sunday 19 Jul 2015 21:01 CEST, Ian Kelly wrote: >> >>> On Sun, Jul 19, 2015 at 10:10 AM, Cecil Westerhof wrote: On Sunday 19 Jul 2015 15:42 CEST, Mark Lawrence wrote: > On 19/07/2015 03:13, Terry Reedy wrote: >> On 7/18/2015 7:50 PM, Devin Jeanpierre wrote: >>> to 2.7, surely bug fixes are also allowed? >> >> Of course, allowed. But should they be made, and if so, by who? > > The people who want the fixes. Babies want clean diapers. So babies have to change diapers themselves? >>> >>> Poor analogy. Babies need others to change their diapers for them >>> because they're not capable of doing it for themselves. >> >> That is why I think it is good analogy. I think that most of the >> users of 2.7 who would be delighted with fixes would have no idea >> how to get those fixes into 2.7. >> > > They could try reading the development guide to start with, or is > that also too much to ask? My impression is that you and some other people are in an ivory tower and find it very cosy. It reminds me about the man on dry land who responded to the person who fell in water and shouted “Help, I cannot swim!” with “Why are you screaming? I cannot swim also. Do you hear me yelling about it?" -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof -- https://mail.python.org/mailman/listinfo/python-list
Re: Is this a good way to work with init and exception
On Mon, Jul 20, 2015 at 8:19 AM, Cecil Westerhof wrote: >> If two modules import the same module, they get two references to >> that same module, not two separate module instances. Since your >> parameters appear only to affect the initialization itself, this is >> not likely to be a problem (it's not like you'll need to >> authenticate with two different sets of credentials, for instance), >> but it will mean that the second one will import an >> already-initialized module. That's why I suggested the try_init >> function which would quietly return an immediate success if the >> module had already been initialized. But if this isn't going to be >> an issue, then your code's fine. > > Good to know. I would expect two different instances. > > I agree that in my case it would not be a problem, but I put the code > on GitHub: > > https://github.com/CecilWesterhof/PythonLibrary/blob/master/twitterDecebal.py > I should do my best to circumvent nasty surprises for users of the > code. Someone else could use several Twitter accounts at the same > time. Is there a way to do this? Does the instantiation of Core() involve authentication? Is it possible to call Core() more than once and use different accounts? Your send_message() takes an account identifier, so it might be you don't need separate accounts. But if, just very occasionally, you do need multiple, here's a possible design style: Have init() return the Core as well as stashing it in _core, and then have send_message() take an optional keyword argument (in 3.x, keyword-only) to choose a different core. That way, it'll by default use the most recently initialized core, but you can create multiple and manage them yourself if you so choose. (Obviously you'd use reinit_allowed=True for all the initializations.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On 19/07/2015 23:10, Cecil Westerhof wrote: On Sunday 19 Jul 2015 22:28 CEST, Mark Lawrence wrote: On 19/07/2015 21:05, Cecil Westerhof wrote: On Sunday 19 Jul 2015 21:01 CEST, Ian Kelly wrote: On Sun, Jul 19, 2015 at 10:10 AM, Cecil Westerhof wrote: On Sunday 19 Jul 2015 15:42 CEST, Mark Lawrence wrote: On 19/07/2015 03:13, Terry Reedy wrote: On 7/18/2015 7:50 PM, Devin Jeanpierre wrote: to 2.7, surely bug fixes are also allowed? Of course, allowed. But should they be made, and if so, by who? The people who want the fixes. Babies want clean diapers. So babies have to change diapers themselves? Poor analogy. Babies need others to change their diapers for them because they're not capable of doing it for themselves. That is why I think it is good analogy. I think that most of the users of 2.7 who would be delighted with fixes would have no idea how to get those fixes into 2.7. They could try reading the development guide to start with, or is that also too much to ask? My impression is that you and some other people are in an ivory tower and find it very cosy. It reminds me about the man on dry land who responded to the person who fell in water and shouted “Help, I cannot swim!” with “Why are you screaming? I cannot swim also. Do you hear me yelling about it?" You are now suggesting that people shouldn't even bother reading the develoment guide, just great. Do they have to do anything themselves to get patches through? Presumably the core devs give up their paid work, holidays, families, other hobbies and the like, just so some bunch of lazy, bone idle gits can get what they want, for nothing, when it suits them? It appears that babies aren't the only people who need their nappies changing around here. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On 7/19/2015 1:53 AM, dieter wrote: Mark Lawrence writes: ... If the vast majority of Python programmers are focused on 2.7, why are volunteers to help fix 2.7 bugs so scarce? I have not done much work related to Python bug fixing. But, I had bad experience with other open source projects: many of my patches (and bug reports) have been ignored over decades. This caused me to change my attitude: I now report bugs (sometimes with patches) and publish a potential solution in a separate package (--> "dm.zopepatches.*", "dm.zodbpatches.*"). This way, affected people can use a solution even if the core developpers don't care. Patches uploaded to the cpython tracker are public and can be and sometimes are used by other people without or before being officially applied. Separate packages are fine too. From my point of view: if you want help with fixing bugs, you must ensure that there is a high probability that those contributions really find their way into the main development lines. As I understand from other messages in this thread, this is also a problem with Python bug fixing. Yes. There are two competing proposals (PEPs) for improvement waiting for a decision from an appointed judge. Does they all consider it perfect (or sufficient) as is? I have not much blame for Python 2.7. I see a few minor points * "pdb" is quite weak - but I could fix some (but by far not all) aspects in "dm.pdb". This is not a security issue, so enhancements cannot go in 2.7. * "https" has been weakly handled in earlier versions, but someone has done the Python 3 backport work in an external package before the backport finally arrived in Python 2.7. This was determined to be an internet security fix. Should the core developers who do not personally use 2.7 stop backporting, because no one cares if they do? I am grateful that the above mentioned "https" backport was finally integrated into Python 2.7 -- even though I find it acceptable to use an external package to get it. Thus, there are people who care. Of course, I will not tell core developers that they must do backporting. If they don't more external packages will come into existence which contain (unofficial) backports. Some core developers have backported new modules they wrote as external packages. Thank you for your comments. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Need assistance
On Thursday, July 16, 2015 at 9:16:01 PM UTC-5, [email protected] wrote: > I need help writing a homework program. > > I'll write it, but I can't figure out how to incorporate what I have read in > the book to work in code. > > The assignment wants us to take a users first, middle and last name in a > single input ( name=('enter your full name: )). > > Then we must display the full name rearranged in Last, First Middle order. > > I tried to use the search function in Python to locate any spaces in the > input. It spot back the index 5 (I used Craig Daniel Sirna) > > That is correct for the first space, but I can't figure out how to get it to > continue to the next space. > > The indexing process is also a bit confusingto me. > > I get that I can use len(fullName) to set the length of the index, and how > the index is counted, but after that I'm lost. > > I have emailed my professor a few times, but haven't gotten a > response.(online course) > > Any help would be greatly appreciated. def main(): name= input('Enter your full name: ') split=name.split() Full_name=split[2],split[0], split[1] print(Full_name[2],',', Full_name[0], Full_name[1]) main() Sorry it took so long to get back to you guys and I greatly appreciate all the help!!! But I just did it now and it does work. I have been working on my College algebra homework for the past week and I am still not even finished or ready for the testfml -- https://mail.python.org/mailman/listinfo/python-list
Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]
On 7/19/2015 3:32 AM, Rustom Mody wrote: Unix bc: $ bc bc 1.06.95 Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. 4+5 9 obase=8 4+5 11 IOW bc has two (global) variables ibase and obase for input and output base. If you dont provide these as settable you hardwire them at 10 (8/16 in some assembly languages)¹ Hopefully you will agree that python is more full-featured than bc and should subsume bc functionality? Nice try ;-) However, I think is not especially relevant. I do not believe that Guido would agree that bc should govern python design. Do *you* really think that? Python is fundamentally a general purpose batch-mode language. Interactive mode is secondary and generally subservient to writing real programs. I know that he has said that he is not inclined to add additional interactive-mode-only features to Python. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Is this a good way to work with init and exception
On Monday 20 Jul 2015 00:40 CEST, Chris Angelico wrote: > On Mon, Jul 20, 2015 at 8:19 AM, Cecil Westerhof wrote: >>> If two modules import the same module, they get two references to >>> that same module, not two separate module instances. Since your >>> parameters appear only to affect the initialization itself, this >>> is not likely to be a problem (it's not like you'll need to >>> authenticate with two different sets of credentials, for >>> instance), but it will mean that the second one will import an >>> already-initialized module. That's why I suggested the try_init >>> function which would quietly return an immediate success if the >>> module had already been initialized. But if this isn't going to be >>> an issue, then your code's fine. >> >> Good to know. I would expect two different instances. >> >> I agree that in my case it would not be a problem, but I put the >> code on GitHub: >> https://github.com/CecilWesterhof/PythonLibrary/blob/master/twitterDecebal.py >> I should do my best to circumvent nasty surprises for users of the >> code. Someone else could use several Twitter accounts at the same >> time. Is there a way to do this? > > Does the instantiation of Core() involve authentication? Is it > possible to call Core() more than once and use different accounts? > Your send_message() takes an account identifier, so it might be you > don't need separate accounts. But if, just very occasionally, you do > need multiple, here's a possible design style: Have init() return > the Core as well as stashing it in _core, and then have > send_message() take an optional keyword argument (in 3.x, > keyword-only) to choose a different core. That way, it'll by default > use the most recently initialized core, but you can create multiple > and manage them yourself if you so choose. (Obviously you'd use > reinit_allowed=True for all the initializations.) You are right: core is a general initialisation, so in this case nothing to worry about. :-D When I write something where it could make a difference, I should use your tip. -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Monday 20 Jul 2015 00:51 CEST, Mark Lawrence wrote: > On 19/07/2015 23:10, Cecil Westerhof wrote: >> On Sunday 19 Jul 2015 22:28 CEST, Mark Lawrence wrote: >> >>> On 19/07/2015 21:05, Cecil Westerhof wrote: On Sunday 19 Jul 2015 21:01 CEST, Ian Kelly wrote: > On Sun, Jul 19, 2015 at 10:10 AM, Cecil Westerhof > wrote: >> On Sunday 19 Jul 2015 15:42 CEST, Mark Lawrence wrote: >> >>> On 19/07/2015 03:13, Terry Reedy wrote: On 7/18/2015 7:50 PM, Devin Jeanpierre wrote: > to 2.7, surely bug fixes are also allowed? Of course, allowed. But should they be made, and if so, by who? >>> >>> The people who want the fixes. >> >> Babies want clean diapers. So babies have to change diapers >> themselves? > > Poor analogy. Babies need others to change their diapers for > them because they're not capable of doing it for themselves. That is why I think it is good analogy. I think that most of the users of 2.7 who would be delighted with fixes would have no idea how to get those fixes into 2.7. >>> >>> They could try reading the development guide to start with, or is >>> that also too much to ask? >> >> My impression is that you and some other people are in an ivory >> tower and find it very cosy. >> >> It reminds me about the man on dry land who responded to the person >> who fell in water and shouted >> “Help, I cannot swim!” >> with >> “Why are you screaming? >> I cannot swim also. >> Do you hear me yelling about it?" >> > > You are now suggesting that people shouldn't even bother reading the > develoment guide, just great. Do they have to do anything themselves > to get patches through? Presumably the core devs give up their paid > work, holidays, families, other hobbies and the like, just so some > bunch of lazy, bone idle gits can get what they want, for nothing, > when it suits them? It appears that babies aren't the only people > who need their nappies changing around here. No use replying anymore. You make a caricature of what I am saying and put words in my mouth I never said. Just stay in your cosy ivory tower. But please do not pretend that you are open for discussion, because you are not. -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof -- https://mail.python.org/mailman/listinfo/python-list
Re: Need assistance
On 07/19/2015 05:06 PM, [email protected] wrote: > def main(): name= input('Enter your full name: ') > split=name.split() > Full_name=split[2],split[0], split[1] > print(Full_name[2],',', Full_name[0], Full_name[1]) > > main() > > Sorry it took so long to get back to you guys and I greatly > appreciate all the help!!! > > But I just did it now and it does work. I have been working on my > College algebra homework for the past week and I am still not even > finished or ready for the testfml Now do you understand why it works and how? For example, if I said that the "full_name=" line is redundant, do you understand why? -- https://mail.python.org/mailman/listinfo/python-list
Re: Need assistance
On Sunday, July 19, 2015 at 6:07:14 PM UTC-5, [email protected] wrote: > def main(): > name= input('Enter your full name: ') > split=name.split() > Full_name=split[2],split[0], split[1] > print(Full_name[2],',', Full_name[0], Full_name[1]) > > main() Sorry, but this code is no where near done yet. What happens when the user enters invalid input? *BANG* > split=name.split() Unpacking those variables would be wiser, and syntactically cleaner, than storing them behind a single variable. And split is a horrible symbol choice. first, middle, and last would be more descriptive. > Full_name=split[2],split[0], split[1] > print(Full_name[2],',', Full_name[0], Full_name[1]) Yuck. Too noisy. Always try to keep indexing to a minimum. And never, ever, repeat yourself. VALIDATE_YOUR_INPUT + REMOVE_THE_NOISE = A+ EXTRA_CREDIT: Repeatedly ask for input until validation passes. EXTRA_EXTRA_CREDIT: Allow clean exit if the user declines input. -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On 20/07/2015 00:23, Cecil Westerhof wrote: On Monday 20 Jul 2015 00:51 CEST, Mark Lawrence wrote: On 19/07/2015 23:10, Cecil Westerhof wrote: On Sunday 19 Jul 2015 22:28 CEST, Mark Lawrence wrote: On 19/07/2015 21:05, Cecil Westerhof wrote: On Sunday 19 Jul 2015 21:01 CEST, Ian Kelly wrote: On Sun, Jul 19, 2015 at 10:10 AM, Cecil Westerhof wrote: On Sunday 19 Jul 2015 15:42 CEST, Mark Lawrence wrote: On 19/07/2015 03:13, Terry Reedy wrote: On 7/18/2015 7:50 PM, Devin Jeanpierre wrote: to 2.7, surely bug fixes are also allowed? Of course, allowed. But should they be made, and if so, by who? The people who want the fixes. Babies want clean diapers. So babies have to change diapers themselves? Poor analogy. Babies need others to change their diapers for them because they're not capable of doing it for themselves. That is why I think it is good analogy. I think that most of the users of 2.7 who would be delighted with fixes would have no idea how to get those fixes into 2.7. They could try reading the development guide to start with, or is that also too much to ask? My impression is that you and some other people are in an ivory tower and find it very cosy. It reminds me about the man on dry land who responded to the person who fell in water and shouted “Help, I cannot swim!” with “Why are you screaming? I cannot swim also. Do you hear me yelling about it?" You are now suggesting that people shouldn't even bother reading the develoment guide, just great. Do they have to do anything themselves to get patches through? Presumably the core devs give up their paid work, holidays, families, other hobbies and the like, just so some bunch of lazy, bone idle gits can get what they want, for nothing, when it suits them? It appears that babies aren't the only people who need their nappies changing around here. No use replying anymore. You make a caricature of what I am saying and put words in my mouth I never said. Just stay in your cosy ivory tower. But please do not pretend that you are open for discussion, because you are not. Thank goodness for that as you make no sense at all. As for this ivory tower nonsense, you clearly haven't bothered reading anything I've said about the proposed improvements to the core workflow. But then of course you wouldn't bother with that, you again expect somebody else to do all the work for you, for free, and probably still complain that the benefits that you're getting aren't enough. Quite frankly your attitude throughout this thread makes me puke. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sunday, July 19, 2015 at 10:27:58 PM UTC+1, Rick Johnson wrote: > On Sunday, July 19, 2015 at 3:36:21 PM UTC-5, [email protected] wrote: > > Wrong, not all programmers need the patches as a lot of > > people couldn't care two hoots about 2.7. > > Well you should. Because apparently, you're incapable of > recognizing that Py2 and Py3 are existentially joined at the > hip! The world of language survival is more complex than your > selfish desires. Wrong again, 2.7 doesn't have all the goodies now poring into 3.x, so there is nothing in 2.7 to make me care. Further as I'm a one man band I do what I like, so having canned it several years back, as have many core devs, it's staying canned. "Selfish desires", very funny, I'll have to remember that one, you really are excelling yourself. > > If you're unable to draw parallels between py2 and py3, > it's only because your focused is far too narrow. Negative > perception of py2 translates to negative perception of py3. I have no negative perception of 2.7, it simply no longer interests me, to repeat in the same way that it no longer interests some core devs. > > Python is the sum of all it's parts. Not merely the small > part (or rattle) that you happen to find amusing. And since > py3 is the smallest part of Python, and py2 is the largest, > you would be wise to consider the consequences of a failed, > or even perceived failure, of Py2. 2.7 is pretty much rock steady Eddie, so it is never going to be a perceived failure, let alone an actual failure. > > If you change the diapers in Py3 nursery but refuse to change > them in Py2 nursery, you might alleviate the your diaper rash, > but other babies poop will always smell worse than your own! I'll repeat, those who want 2.7 supported do the work, can it get any simpler? You can support it, or are you still too busy working on your fork, RickedPython? I'm not interested in it, I'm wouldn't touch it even if someone offered to pay me, end of story. -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sunday, July 19, 2015 at 7:28:28 PM UTC-5, Mark Lawrence wrote: > Thank goodness for that as you make no sense at all. As > for this ivory tower nonsense, [...] Cecil, don't pay too much attention to Mark, he's a glory hound. He's like the Python community version of Cerberus -- you know, the three headed dog guarding the entrance to the Greek underworld. Every time i defeat him, and drag him out through an opening in the "caverns of code", and take him to a secret grove owned by D'Aprano, he always escapes and returns to guard the entrance again -- he's very loyal! He won't allow you to enter because you're still alive, and as such, you still have the capacity to "feel" emotions like compassion. These emotions are forbidden in the underworld!!! But don't worry, his bark is worse than his bite, and he is just the first of many daemons you must defeat on your quest to challenge the benevolent Hades. -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sat, Jul 18, 2015 at 9:45 PM, Steven D'Aprano wrote: >> It gets really boring submitting 2.7-specific patches, though, when >> they aren't accepted, and the committers have such a hostile attitude >> towards it. I was told by core devs that, instead of fixing bugs in >> Python 2, I should just rewrite my app in Python 3. > > Really? Can you point us to this discussion? Yes, really. It was on #python-dev IRC. > If you are right, and that was an official pronouncement, then it seems that > non-security bug fixes to 2.7 are forbidden. I never said it was a pronouncement, or official. It wasn't. I have no idea where you got that idea from, given that I specifically have said that I think non-security bug fixes are allowed. > I suspect though that it's not quite that black and white. Perhaps there was > some doubt about whether or not the patch in question was fixing a bug or > adding a feature (a behavioural change). Or the core dev in question was > speaking for themselves, not for all. They weren't speaking for all. And, I never said they were. Nor did I imply that they were. Search your logs for https://bugs.python.org/issue17094 and http://bugs.python.org/issue5315 I was most frustrated by the first case -- the patch was (informally) rejected in favor of the "right" fix, and the "right" fix was (informally) rejected because it changed behavior, leaving me only with the option of absurd workarounds of a bug in Python, or moving to python 3. >> It has even been >> implied that bugs in Python 2 are *good*, because that might help with >> Python 3 adoption. > > Really? Can you point us to this discussion? > > As they say on Wikipedia, Citation Needed. I would like to see the context > before taking that at face value. Of course, it was a joke. The format of the joke goes like this: people spend a lot of time debugging and writing bugfixes for Python 2.7, and you say: guido wants all python 3 features in python 2, so ssbr` maybe choose the right time to ask a backport ;-) oh. if i would be paid to contribute to cpython, i would probably be ok to backport anything from python 3 to python 2 since i'm not paid for that, i will to kill python 2, it must suffer a lot And that's about as close to logs as I am comfortable posting. Grep your logs for that, too. I don't like how this is being redirected to "surely you misunderstood" or "I don't believe you". The fact that some core devs are hostile to 2.x development is really bleedingly obvious, you shouldn't need quotes or context thrown at you. The rhetoric almost always shies _just_ short of ceasing bugfixes (until 2020, when that abruptly becomes a cracking good idea). e.g. in "2.7 is here until 2020, please don't call it a waste". I don't want to argue over who said what. I am sure everyone meant the best, and I misunderstood them given a complicated context and a rough day. Let's end this thread here, please. -- Devin -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sunday, July 19, 2015 at 7:45:43 PM UTC-5, [email protected] wrote: > I have no negative perception of 2.7, it simply no longer > interests me, to repeat in the same way that it no longer > interests some core devs. Your apathy towards Py2 will not shield you from the collateral damage caused by it's demise. What matters is what the *WORLD* thinks about Python. And if the global "perception" is that: "Python is buggy", or that: "the python community is fractured" -> then all hope in widespread future adoption is gone! Then, both Py2 and Py3 die. Then, you will be forced to use another language? GOT IT? This is *NOT* about you, or me, this is about the *PERCEPTION* of Python within the *ENTIRE* programming community. > are you still too busy working on your fork, RickedPython? I've never seen you before. Are you a regular hiding behind a fake name? -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Monday, July 20, 2015 at 1:49:58 AM UTC+1, Rick Johnson wrote: > On Sunday, July 19, 2015 at 7:28:28 PM UTC-5, Mark Lawrence wrote: > > > Thank goodness for that as you make no sense at all. As > > for this ivory tower nonsense, [...] > > Cecil, don't pay too much attention to Mark, he's a glory > hound. He's like the Python community version of Cerberus -- > you know, the three headed dog guarding the entrance to the > Greek underworld. > > Every time i defeat him, and drag him out through an opening in > the "caverns of code", and take him to a secret grove owned > by D'Aprano, he always escapes and returns to guard the > entrance again -- he's very loyal! > > He won't allow you to enter because you're still alive, and > as such, you still have the capacity to "feel" emotions like > compassion. These emotions are forbidden in the underworld!!! > > But don't worry, his bark is worse than his bite, and he is > just the first of many daemons you must defeat on your quest > to challenge the benevolent Hades. Gosh you don't half spout some rubbish. Your total number of victories over me is zero, although I personally come here to give or get knowledge, not look for such things. As for the cobblers about Cerburus and "challenging the benevolent Hades" would you be kind enough to:- a) list just how many Python bugs you have worked on b) state how much work you intend doing on the planned core workflow improvements For the latter you can find the relevant PEPs easily enough for yourself, or just like Cecil do you expect someone to do that for you as well? -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sunday, July 19, 2015 at 8:26:52 PM UTC-5, [email protected] wrote: > On Monday, July 20, 2015 at 1:49:58 AM UTC+1, Rick Johnson wrote: > > On Sunday, July 19, 2015 at 7:28:28 PM UTC-5, Mark Lawrence wrote: > > Every time i defeat [MARK LAWRENCE], and drag him out > > through an opening in the "caverns of code", and take > > him to a secret grove owned by D'Aprano, he always > > escapes and returns to guard the entrance again -- he's > > very loyal! > > Your total number of victories over me is zero, although I > personally come here to give or get knowledge, not look > for such things. I figured that was you *MARK LAWRENCE*. I shall add sock-puppeting to your many egregious offenses! And poorly executed sock-puppeting as well! You're a zero. -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On 20/07/2015 02:20, Devin Jeanpierre wrote: I don't like how this is being redirected to "surely you misunderstood" or "I don't believe you". The fact that some core devs are hostile to 2.x development is really bleedingly obvious, you shouldn't need quotes or context thrown at you. The rhetoric almost always shies _just_ short of ceasing bugfixes (until 2020, when that abruptly becomes a cracking good idea). e.g. in "2.7 is here until 2020, please don't call it a waste". A couple of things. First "some core devs are hostile", actually some have stated that they're simply not interested in 2.7 and will not work on it. Second how has the thread got here, as it was originally asking about back porting bug fixes from 3.x to 2.7? Further it said:- If the vast majority of Python programmers are focused on 2.7, why are volunteers to help fix 2.7 bugs so scarce? So I most humbly suggest, as I may have hinted at once or twice earlier in this thread, that people either put up or shut up. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]
On Monday, July 20, 2015 at 4:43:57 AM UTC+5:30, Terry Reedy wrote: > On 7/19/2015 3:32 AM, Rustom Mody wrote: > > > Unix bc: > > $ bc > > bc 1.06.95 > > Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, > > Inc. > > This is free software with ABSOLUTELY NO WARRANTY. > > For details type `warranty'. > > 4+5 > > 9 > > obase=8 > > 4+5 > > 11 > > > > IOW bc has two (global) variables ibase and obase for input and output base. > > If you dont provide these as settable you hardwire them at 10 (8/16 in some > > assembly languages)¹ > > > > Hopefully you will agree that python is more full-featured than bc and > > should > > subsume bc functionality? > > Nice try ;-) However, I think is not especially relevant. I do not > believe that Guido would agree that bc should govern python design. Do > *you* really think that? Python is fundamentally a general purpose > batch-mode language. Interactive mode is secondary and generally > subservient to writing real programs. I know that he has said that he > is not inclined to add additional interactive-mode-only features to Python. We will have to agree to disagree then. I wrote this in 2012 (that is to say not in context of this discussion): http://blog.languager.org/2012/10/functional-programming-lost-booty.html in which I list an REPL as one of the factors that distinguish a modern, powerful v hi-level language from stodgy old-fashioned blub languages. Regarding your earlier points about idle, I think you are (to use a traditional OS metaphor) mixing up policy with mechanism. Policy: Having a REPL (things like Idle) Mechanism: How exactly its bundled eg in pythonland python the interpreter and the interactive version are the same executable functioning in different modes In other languages (haskell has ghci, ruby has irb) the interactive interpreter is a different program (just a thin wrapper) on the main interpreter (compiler for haskell) Likewise in debian (ubuntu) vs windows the bundling is v different. In debian python comes for free and the system would not work without it but tkinter, idle etc need to be installed with their dependencies In windows, one needs to install one bundle and one gets the whole lot... Of course as recently discussed, it may be time to have ipython replace vanilla python and therefore break that off from the core. These are (to me) minor points compared to the existence/non-existence of an interactive interpreter. -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Monday, July 20, 2015 at 7:16:50 AM UTC+5:30, Mark Lawrence wrote:
> On 20/07/2015 02:20, Devin Jeanpierre wrote:
>
> >
> > I don't like how this is being redirected to "surely you
> > misunderstood" or "I don't believe you". The fact that some core devs
> > are hostile to 2.x development is really bleedingly obvious, you
> > shouldn't need quotes or context thrown at you. The rhetoric almost
> > always shies _just_ short of ceasing bugfixes (until 2020, when that
> > abruptly becomes a cracking good idea). e.g. in "2.7 is here until
> > 2020, please don't call it a waste".
> >
>
> A couple of things.
>
> First "some core devs are hostile", actually some have stated that
> they're simply not interested in 2.7 and will not work on it.
>
> Second how has the thread got here, as it was originally asking about
> back porting bug fixes from 3.x to 2.7? Further it said:-
>
>
> If the vast majority of Python programmers are focused on 2.7, why are
> volunteers to help fix 2.7 bugs so scarce?
>
>
> So I most humbly suggest, as I may have hinted at once or twice earlier
> in this thread, that people either put up or shut up.
I just ran the following command
$ hg log --template "{author|person}\n" | sort | uniq -c | sort -nr
as giving all the committers to python in sorted order.
I get the list below.
Dont see any Mark Lawrence there
Of course I dont know hg at all well... Just picked up the above command from
http://stackoverflow.com/questions/6126678/how-to-list-commiters-sorted-by-number-of-commits-commit-count
So... May I humbly ask where are your precious commits??
List of python committers:
-
11081 Guido van Rossum
6172 Fred Drake
6120 Georg Brandl
5603 Benjamin Peterson
4077 Raymond Hettinger
3874 Victor Stinner
3774 Antoine Pitrou
3157 Jack Jansen
3089 Martin v. Löwis
2668 Tim Peters
2372 Serhiy Storchaka
2219 Andrew M. Kuchling
2205 Barry Warsaw
2038 Ezio Melotti
2016 Neal Norwitz
2009 Mark Dickinson
1966 Brett Cannon
1307 R David Murray
1180 Christian Heimes
1159 Senthil Kumaran
1108 Gregory P. Smith
1075 Éric Araujo
1071 Vinay Sajip
1065 Jeremy Hylton
903 Tarek Ziadé
872 Greg Ward
871 Thomas Heller
780 R. David Murray
777 Terry Jan Reedy
728 Skip Montanaro
695 Nick Coghlan
687 Ned Deily
581 Ronald Oussoren
579 Walter Dörwald
527 Kurt B. Kaiser
519 Michael W. Hudson
511 Amaury Forgeot d'Arc
481 Stefan Krah
450 Andrew Svetlov
432 Thomas Wouters
423 Zachary Ware
422 Anthony Baxter
403 Brian Curtin
400 Florent Xicluna
387 Eli Bendersky
383 Eric Smith
370 Hirokazu Yamamoto
364 Charles-François Natali
362 Alexander Belopolsky
354 Just van Rossum
344 Marc-André Lemburg
340 Alexandre Vassalotti
334 Michael Foord
317 Neil Schemenauer
314 Fredrik Lundh
293 Jesus Cea
285 Sandro Tosi
282 Larry Hastings
264 Yury Selivanov
260 Matthias Klose
259 Berker Peksag
239 Richard Oudkerk
233 Nadeem Vawda
202 Kristján Valur Jónsson
189 Petri Lehtinen
174 Collin Winter
166 Lars Gustäbel
163 Hye-Shik Chang
159 Mark Hammond
159 Facundo Batista
156 Armin Rigo
154 Andrew MacIntyre
153 Steve Dower
153 doko
153 Chris Jerdonek
152 Sjoerd Mullender
123 Łukasz Langa
121 cvs2svn
118 Giampaolo Rodolà
112 Andrew Kuchling
109 Guilherme Polo
109 Giampaolo Rodola'
106 Eric Snow
102 Ka-Ping Yee
101 Meador Inge
101 Jesse Noller
101 Jason R. Coombs
97 Trent Nelson
97 Steven M. Gava
96 Hynek Schlawack
93 Tim Golden
93 Eric S. Raymond
91 Ethan Furman
87 Moshe Zadka
87 Johannes Gijsbers
87 Jeffrey Yasskin
79 Roger E. Masse
77 Ross Lagerwall
67 Donald Stufft
65 George Yoshida
63 Phillip J. Eby
63 Philip Jenvey
62 Gustavo Niemeyer
59 Jeroen Ruigrok van der Werven
58 Steven Bethard
51 Eric V. Smith
50 Roger Serwy
46 Bob Ippolito
45 Terry Reedy
45 Peter Schneider-Kamp
45 Gerhard Häring
42 Tarek Ziade
42 Edward Loper
40 Peter Astrand
39 Alex Martelli
38 Daniel Stutzbach
37 Sean Reifscheider
37 Jason Tishler
36 Bill Janssen
34 Trent Mick
34 Piers Lauder
33 Jack Diederich
31 Mark Summerfield
31 Jim Fulton
29 Greg Stein
28 Nicholas Bastin
27 Andrew McNamara
23 Robert Schuppenies
23 Josiah Carlson
22 Vladimir Marangozov
21 Kristjan Valur Jonsson
21 Brian Quinlan
20 Paul Prescod
18 Tony Lownds
18 Steve Purcell
18 Andrew Dalke
17 Finn Bock
17 David Wolever
16 Steve Holden
16 Robert Collins
16 Jean-Paul Calderone
16 Charles-Francois Natali
15 Žiga Seilnacht
15 David Malcolm
15 Armin Ronacher
14 Travis E. Oliphant
Re: Should non-security 2.7 bugs be fixed?
On Mon, 20 Jul 2015 05:01 am, Ian Kelly wrote: > On Sun, Jul 19, 2015 at 10:10 AM, Cecil Westerhof > wrote: >> On Sunday 19 Jul 2015 15:42 CEST, Mark Lawrence wrote: >> >>> On 19/07/2015 03:13, Terry Reedy wrote: On 7/18/2015 7:50 PM, Devin Jeanpierre wrote: > to 2.7, surely bug fixes are also allowed? Of course, allowed. But should they be made, and if so, by who? >>> >>> The people who want the fixes. >> >> Babies want clean diapers. So babies have to change diapers >> themselves? > > Poor analogy. Babies need others to change their diapers for them > because they're not capable of doing it for themselves. Good analogy. Most Python programmers are no more able to write patches for Python than babies are able to change their own nappy. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Off-topic: Europe [was Re: Noob in Python. Problem with fairly simple test case]
On Mon, 20 Jul 2015 03:25 am, Rick Johnson wrote: > On Sunday, July 19, 2015 at 4:18:31 AM UTC-5, Laura Creighton wrote: >> And, despite Norway not being part of the EU, Scandinavia >> is still in Europe. > > This is a bit off topic: But i don't consider Scandinavia to > be a part of the EU. Laura didn't say that Scandinavia (Finland, Sweden, Norway, Denmark) is part of the European Union (a political union), she explicitly stated that Norway is not. But it is part of Europe, which is a geographical area that runs from Ireland to the Ural mountains in Russia, from the Mediterranean to the Arctic Circle. > Not anymore than i would consider > America to be a part of the EU. Sure, we're all colloquially > known as "the west", "The West" has nothing to do with this. But for the record, "the West" includes Australia and New Zealand, which are in the south-east. > The only ubiquitous > binding agent between all the member countries is the > existential need to conglomerate military power against foes > in the east. You're thinking of NATO. The EU is primarily a political union designed to reduce the cost of business when dealing with other European countries. If it has any military influence, it is that countries that allow free trade and travel between themselves are less likely to war on each other than those that don't. Germany is less likely to invade France again, so long as German business and French business are all part of the same business. At least the sort of war that involves actual shooting. [Disclaimer: countries that have little or no contact at all are even less likely to go to war against each other.] > Beyond that, the union is superficial at best. > If the bailout fails, or another worldwide financial crisis > hits, the outcome could be disastrous for the EU. Actually, the best thing for the EU right now would probably be for Greece to withdraw from the Euro and float their own currency, but otherwise remain in the EU. Not only would that be the best outcome for Greece, but it would give the German bureaucrats and the Troika a kick to the seat of their pants for attempting to interfere in the democratic process. > When those pension checks stop coming in the mail, people get > violent! The pension cheques stopped coming about 18 months ago, and despite austerity, despite putting millions of people out of work, despite sticking a railway spike into the Greek economy (or perhaps because of these three factors) Greece owes more money now than it did when the Germans declared economic war on them on behalf of the banks. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Mon, 20 Jul 2015 06:21 am, [email protected] wrote: > All in all though I have to admit that overall it's a really onerous task. > Once you've produced the patch you have to go to all the trouble of > logging on to the issue tracker, finding the appropriate issue and > uploading the patch. You may even be inclined to make a comment. In this > case this entire process could take as much as two whole minutes. It's very interesting that you ignore the two hardest parts of the process: (1) Producing the patch in the first place. (2) Convincing those with appropriate commit rights to accept the patch. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Mon, 20 Jul 2015 08:51 am, Mark Lawrence wrote: > You are now suggesting that people shouldn't even bother reading the > develoment guide, just great. Do they have to do anything themselves to > get patches through? Presumably the core devs give up their paid work, > holidays, families, other hobbies and the like, just so some bunch of > lazy, bone idle gits can get what they want, for nothing, when it suits > them? Just a reminder that at least some of the core devs, including Guido, are paid to work on Python. And another reminder that open source software doesn't have any restrictions about only distributing software to those who are willing and able to write patches for it. Anyone can use Python, including children and non-programmers. Being able to hack on the interpreter C code and produce quality patches is not a pre-requisite. I know that I've reported bugs in Python that I was unqualified or incapable of fixing, at least without going through months or years of learning. At least one of those bugs has been fixed by others who have the skills. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Mon, Jul 20, 2015 at 12:16 PM, Rustom Mody wrote:
> I just ran the following command
> $ hg log --template "{author|person}\n" | sort | uniq -c | sort -nr
>
> as giving all the committers to python in sorted order.
> I get the list below.
> Dont see any Mark Lawrence there
> Of course I dont know hg at all well... Just picked up the above command from
> http://stackoverflow.com/questions/6126678/how-to-list-commiters-sorted-by-number-of-commits-commit-count
>
> So... May I humbly ask where are your precious commits??
Same place that mine aren't. Compare:
http://bugs.python.org/issue24610
https://hg.python.org/cpython/rev/02b81a82a57d
(It's a trivial docs patch, but that makes for a better demo than the
messy PEP 479/issue22906 stuff, where different parts got committed at
different times.)
I create a patch on my local clone of the CPython repository, and
rather than push it directly (which technically I _could_ do, but
socially I don't have jurisdiction over the main source code), I
create a tracker issue and attach the patch. Then someone else commits
it - and it's his name that's on the commit. Same here:
http://bugs.python.org/issue24435
https://hg.python.org/cpython/rev/a9c34db88d79
No matter how many patches I write (not that I write very many), I
won't show up on your list unless I actually push my own code. Mark
isn't a core committer, so you won't see him. A quick search of the
tracker came up with this:
http://bugs.python.org/issue19980
It's a closed issue with a patch by Mark Lawrence. (There may well be
others, I have no idea. All I know is that this one came up in the
search.) The author of the resulting commit is Serhiy, not Mark, so
that's who you'll be counting in your stats.
Sorry to say, the flaw is in your testing methodology.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Monday, July 20, 2015 at 6:19:58 AM UTC+5:30, Rick Johnson wrote: > But don't worry, his bark is worse than his bite, and he is > just the first of many daemons you must defeat on your quest > to challenge the benevolent Hades. Do you give lessons in rhetoric Rick? -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Mon, 20 Jul 2015 11:20 am, Devin Jeanpierre wrote: > On Sat, Jul 18, 2015 at 9:45 PM, Steven D'Aprano > wrote: >>> It gets really boring submitting 2.7-specific patches, though, when >>> they aren't accepted, and the committers have such a hostile attitude >>> towards it. I was told by core devs that, instead of fixing bugs in >>> Python 2, I should just rewrite my app in Python 3. >> >> Really? Can you point us to this discussion? > > Yes, really. It was on #python-dev IRC. Ah, pity, because I really would have liked to have seen the context. (I assume there are no archives of #python and #python-dev. At least, I've never found them.) >> If you are right, and that was an official pronouncement, then it seems >> that non-security bug fixes to 2.7 are forbidden. > > I never said it was a pronouncement, or official. It wasn't. I have no > idea where you got that idea from, given that I specifically have said > that I think non-security bug fixes are allowed. You said that core devs told you not to fix bugs in Python 2. Do you really think it's a big stretch to go from "core devs said don't fix Python 2 bugs" to "it's core dev policy to not fix Python 2 bugs"? > Search your logs for https://bugs.python.org/issue17094 and > http://bugs.python.org/issue5315 > > I was most frustrated by the first case -- the patch was (informally) > rejected in favor of the "right" fix, and the "right" fix was > (informally) rejected because it changed behavior, leaving me only > with the option of absurd workarounds of a bug in Python, or moving to > python 3. In the first case, 17094, your comments weren't added until TWO YEARS after the issue was closed. It's quite possible that nobody has even noticed them. In the second case, the issue is still open. So I don't understand your description above: there's no sign that the patch in 17094 was rejected, the patch had bugs and it was fixed and applied to 3.4. It wasn't applied to 2.7 for the reasons explained in the tracker: it could break code that is currently working. For the second issue, it has neither been applied nor rejected. > I don't like how this is being redirected to "surely you > misunderstood" or "I don't believe you". The fact that some core devs > are hostile to 2.x development is really bleedingly obvious, Not to me it isn't. At worst, I would say that some of them are indifferent to 2.7. > you > shouldn't need quotes or context thrown at you. The rhetoric almost > always shies _just_ short of ceasing bugfixes (until 2020, when that > abruptly becomes a cracking good idea). e.g. in "2.7 is here until > 2020, please don't call it a waste". Right. So you take an extended ten year maintenance period for Python 2.7 as evidence that the core devs are *hostile* to maintaining 2.7? That makes no sense to me. If you want to say that *some individuals* who happen to have commit rights are hostile to Python 2.7, I can't really argue with that. Individuals can have all sorts of ideas and opinions. But the core devs as a group are very supportive of Python 2.7, even going to the effort of back-porting performance improvements. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Can't Install Pandas
Hello experts. I odwnloaded Pandas, and put it here. C:\Python34\Scripts\pandas-0.16.2 Then, I ran this in what most people call the c-prompt, but I call it the 'Python 3.4.3 Shell' "C:\Python34\Scripts\pandas-0.16.2>" "pip install 'setup.py'" It seems like everything ran fine, so I try this. import pandas as pd Then I get this error. Traceback (most recent call last): File "", line 1, in import pandas as pd ImportError: No module named 'pandas' Any idea what I'm doing wrong? I tried to follow the instructions here. https://pip.pypa.io/en/latest/installing.html That doesn't work either. python get-pip.py SyntaxError: invalid syntax I won't even ask the most obvious question, because I guess it's impossible to do. Rather, can someone please help me to get this working? Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Mon, 20 Jul 2015 11:35 am, Rick Johnson wrote: > I figured that was you *MARK LAWRENCE*. I shall add sock-puppeting > to your many egregious offenses! And poorly executed sock-puppeting > as well! You're a zero. Rick, what the hell are you talking about? Mark is using the same email address as he has always used (unlike a certain person who shall remain unnamed, but used to go by the names RR and Ranting Rick and possibly others). Neglecting to include a sig containing your name at the bottom of your email is not "sock-puppeting". If it were, you would be guilty of it as well: you don't usually sign your posts. A bit of rough-and-tumble on discussion forums like this is one thing, but I think falsely accusing someone of sock-puppeting is going too far. If you aren't man enough to give Mark an apology, at least be man enough to acknowledge that you made a mistake. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Can't Install Pandas
On Sunday, July 19, 2015 at 11:05:46 PM UTC-4, ryguy7272 wrote: > Hello experts. I odwnloaded Pandas, and put it here. > C:\Python34\Scripts\pandas-0.16.2 > > Then, I ran this in what most people call the c-prompt, but I call it the > 'Python 3.4.3 Shell' > "C:\Python34\Scripts\pandas-0.16.2>" "pip install 'setup.py'" > > It seems like everything ran fine, so I try this. > import pandas as pd > > Then I get this error. > Traceback (most recent call last): > File "", line 1, in > import pandas as pd > ImportError: No module named 'pandas' > > Any idea what I'm doing wrong? > > > I tried to follow the instructions here. > https://pip.pypa.io/en/latest/installing.html > > > That doesn't work either. > python get-pip.py > SyntaxError: invalid syntax > > I won't even ask the most obvious question, because I guess it's impossible > to do. Rather, can someone please help me to get this working? > > Thanks. Well, I got everything to install on the cmd window, but I still can't run anything in the Shell. Here's two simple examples. import numpy as np Traceback (most recent call last): File "", line 1, in import numpy as np ImportError: No module named 'numpy' >>> import pandas as pd Traceback (most recent call last): File "", line 1, in import pandas as pd ImportError: No module named 'pandas' According to what I saw in the cmd window, these two things were installed. Nevertheless, they don't run in the Shell. I guess I spend 95% of my time trying to import stuff, and about 5% of my time doing something interesting or useful with Python. -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sun, Jul 19, 2015 at 9:12 PM, Steven D'Aprano wrote: > On Mon, 20 Jul 2015 11:35 am, Rick Johnson wrote: > >> I figured that was you *MARK LAWRENCE*. I shall add sock-puppeting >> to your many egregious offenses! And poorly executed sock-puppeting >> as well! You're a zero. > > Rick, what the hell are you talking about? Mark is using the same email > address as he has always used (unlike a certain person who shall remain > unnamed, but used to go by the names RR and Ranting Rick and possibly > others). Not quite; one is @yahoo.co.uk, and the other is @gmail.com. If the great Ranting Rick can't tell that these belong to the same person just based on the local part, then what chance do we mere mortals have? -- https://mail.python.org/mailman/listinfo/python-list
Re: Can't Install Pandas
On Mon, Jul 20, 2015 at 1:05 PM, ryguy7272 wrote: > Hello experts. I odwnloaded Pandas, and put it here. > C:\Python34\Scripts\pandas-0.16.2 > > Then, I ran this in what most people call the c-prompt, but I call it the > 'Python 3.4.3 Shell' > "C:\Python34\Scripts\pandas-0.16.2>" "pip install 'setup.py'" > > It seems like everything ran fine Firstly, why would you call it the Python shell? It isn't. Secondly, what gave you the idea that everything ran fine? That is not the command you would use to install something you've already downloaded, nor is it a command that will successfully download and install a package using pip. (Thirdly, what's with the extraneous quotes all over the place?) I suggest you start by learning how to use pip to install packages. If that gives you trouble, *ask for help with pip*, do NOT just say "everything ran fine" and then point out that importing didn't work (which is proof that everything did NOT run fine with the install). If you're going to take a hostile attitude toward Python, *and* waste our time with the way you ask questions, you'll quickly find that people will just delete your posts and move on, which I was just about to do. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sun, Jul 19, 2015 at 8:05 PM, Steven D'Aprano wrote: > On Mon, 20 Jul 2015 11:20 am, Devin Jeanpierre wrote: >> I was most frustrated by the first case -- the patch was (informally) >> rejected in favor of the "right" fix, and the "right" fix was >> (informally) rejected because it changed behavior, leaving me only >> with the option of absurd workarounds of a bug in Python, or moving to >> python 3. > > In the first case, 17094, your comments weren't added until TWO YEARS after > the issue was closed. It's quite possible that nobody has even noticed > them. In the second case, the issue is still open. So I don't understand > your description above: there's no sign that the patch in 17094 was > rejected, the patch had bugs and it was fixed and applied to 3.4. It wasn't > applied to 2.7 for the reasons explained in the tracker: it could break > code that is currently working. > > For the second issue, it has neither been applied nor rejected. I meant search your #python-dev IRC logs, where this was discussed. As far as whether people notice patches after an issue is closed, Terry Reedy answered "yes" earlier in the thread. If the answer is actually "no", then we should fix how bugs are handled post-closure, in case e.g. someone posts a followup patch that fixes a remaining case, and so on. >> you >> shouldn't need quotes or context thrown at you. The rhetoric almost >> always shies _just_ short of ceasing bugfixes (until 2020, when that >> abruptly becomes a cracking good idea). e.g. in "2.7 is here until >> 2020, please don't call it a waste". > > Right. So you take an extended ten year maintenance period for Python 2.7 as > evidence that the core devs are *hostile* to maintaining 2.7? That makes no > sense to me. That isn't what I said at all. > If you want to say that *some individuals* who happen to have commit rights > are hostile to Python 2.7, I can't really argue with that. Individuals can > have all sorts of ideas and opinions. But the core devs as a group are very > supportive of Python 2.7, even going to the effort of back-porting > performance improvements. I do want to say that. It doesn't help that those same individuals are the only core devs I have interacted with while trying to patch 2.7. -- Devin -- https://mail.python.org/mailman/listinfo/python-list
