Re: Pythonic Y2K

On 2019-01-17, Schachner, Joseph wrote: > I'd like to add one more thing to your list of what companies will have to > consider: > > 6) The ability to hire and retain employees who will be happy to >program in an obsolete version of Python. A version about which >new books will probably

Re: Pythonic Y2K

On Wed, Jan 16, 2019 at 9:57 PM Avi Gross wrote: > > The forthcoming UNIX 2038 problem will, paradoxically happen on January 19. I wonder what they will do long before then. Will they just add a byte or four or 256 and then make a date measurable in picoseconds? Or will they start using a number

Re: Pythonic Y2K

On Fri, Jan 18, 2019 at 5:48 AM Schachner, Joseph wrote: > > I'd like to add one more thing to your list of what companies will have to > consider: > > 6) The ability to hire and retain employees who will be happy to program in > an obsolete version of Python. A version about which new books

RE: Pythonic Y2K

: Chris Angelico Sent: Wednesday, January 16, 2019 2:15 PM To: Python Subject: Re: Pythonic Y2K On Thu, Jan 17, 2019 at 6:04 AM Avi Gross wrote: > > I see messages like the following where someone is still asking how to > do something in some version of python 2.X. > > I recall

Re: Pythonic Y2K

On Thu, Jan 17, 2019 at 3:55 PM Avi Gross wrote: > The forthcoming UNIX 2038 problem will, paradoxically happen on January 19. > Paradoxically? What do you mean by that? ChrisA -- https://mail.python.org/mailman/listinfo/python-list

RE: Pythonic Y2K

ssage- From: Python-list On Behalf Of DL Neil Sent: Wednesday, January 16, 2019 11:04 PM To: Python Subject: Re: Pythonic Y2K On 17/01/19 4:45 PM, Larry Martell wrote: > On Wed, Jan 16, 2019 at 9:35 PM Avi Gross wrote: >> >> Chris, >> >> The comparison to Y2K wa

RE: Pythonic Y2K

I can well understand people holding on to what they know, especially when the new stuff is likely to keep changing. Some of that legacy code probably is very un-pythonic and a relatively minimal translation from how it was done in C, when that is possible. Arguably such code might be easi

Re: Pythonic Y2K

On 17/01/19 4:45 PM, Larry Martell wrote: On Wed, Jan 16, 2019 at 9:35 PM Avi Gross wrote: Chris, The comparison to Y2K was not a great one. I am not sure what people did in advance, but all it took was to set the clock forward on a test system and look for anomalies. Not everything would be

Re: Pythonic Y2K

On Wed, Jan 16, 2019 at 9:35 PM Avi Gross wrote: > > Chris, > > The comparison to Y2K was not a great one. I am not sure what people did in > advance, but all it took was to set the clock forward on a test system and > look for anomalies. Not everything would be found but it gave some hints.

RE: Pythonic Y2K

To: Python Subject: Re: Pythonic Y2K On Thu, Jan 17, 2019 at 6:04 AM Avi Gross wrote: > > I see messages like the following where someone is still asking how to > do something in some version of python 2.X. > > I recall the days before the year 2000 with the Y2K scare when pe

Re: Pythonic Y2K

On Thu, Jan 17, 2019 at 6:04 AM Avi Gross wrote: > > I see messages like the following where someone is still asking how to do > something in some version of python 2.X. > > I recall the days before the year 2000 with the Y2K scare when people > worried that legacy software might stop working or

Pythonic Y2K

I see messages like the following where someone is still asking how to do something in some version of python 2.X. I recall the days before the year 2000 with the Y2K scare when people worried that legacy software might stop working or do horrible things once the clock turned. It may even have

Re: Most pythonic way to implement byte stuffing algorithm

n. Though really what this really generalizes to >> is “what is the most pythonic way to transform one sequence of bytes where >> some bytes are passed through 1:1, but others are transformed to longer >> subsequences of bytes?” I’m pretty sure this rules out the use of

Re: Most pythonic way to implement byte stuffing algorithm

On 2018-04-17 17:02, Travis Griggs wrote: I posted this on SO, but… yeah… I'm doing some serial protocol stuff and want to implement a basic byte stuffing algorithm in python. Though really what this really generalizes to is “what is the most pythonic way to transform one sequence of bytes

Re: Most pythonic way to implement byte stuffing algorithm

On 2018-04-17, Travis Griggs <travisgri...@gmail.com> wrote: > I posted this on SO, but… yeah… > > I'm doing some serial protocol stuff and want to implement a basic > byte stuffing algorithm in python. Though really what this really > generalizes to is “what is

Most pythonic way to implement byte stuffing algorithm

I posted this on SO, but… yeah… I'm doing some serial protocol stuff and want to implement a basic byte stuffing algorithm in python. Though really what this really generalizes to is “what is the most pythonic way to transform one sequence of bytes where some bytes are passed through 1:1

[issue32829] Lib/ be more pythonic

R. David Murray added the comment: The risk of introducing a bug is higher than the minimal benefit of making the changes. Thus we do not typically accept changes like this. We'll clean up such code when we touching it for other reasons. -- nosy:

[issue32829] Lib/ be more pythonic

Дилян Палаузов added the comment: The variables got_it in distutils/command/sdist and quote in email/_header_value_parser can be skipped making the code shorter and faster. -- ___ Python tracker

[issue32829] Lib/ be more pythonic

Terry J. Reedy added the comment: Dilyan, please explain what you believe the problems to be and how the patch solves it. These seem to be 3 separate issues. Do not change idlelib.config. config_main.def contain 'default = True' or 'default = False' and that is what the

[issue32829] Lib/ be more pythonic

Christian Heimes added the comment: We generally don't accept patches on bugs.python.org. Please open a pull request on github, see https://devguide.python.org/#contributing -- nosy: +christian.heimes ___ Python tracker

[issue32829] Lib/ be more pythonic

ut it is ignored. """ -- components: Build messages: 312040 nosy: dilyan.palauzov priority: normal severity: normal status: open title: Lib/ be more pythonic type: performance versions: Python 3.8 ___ Python tracker <rep...@bugs.python.org>

Re: What is more Pythonic: subclass or adding functionality to base class?

On 11 February 2018 at 12:55, D'Arcy Cain <da...@vybenetworks.com> wrote: > On 02/11/18 06:30, Victor Porton wrote: >> What is more pythonic? >> >> 1. Create its subclass PredicateParserWithError and add the additional field >> on_error to this class. >> >

Re: What is more Pythonic: subclass or adding functionality to base class?

On 02/11/18 06:30, Victor Porton wrote: > What is more pythonic? > > 1. Create its subclass PredicateParserWithError and add the additional field > on_error to this class. > > 2. Add on_error field to the base class, setting it to None by default, if > the class's user doe

What is more Pythonic: subclass or adding functionality to base class?

e objects of this class. What is more pythonic? 1. Create its subclass PredicateParserWithError and add the additional field on_error to this class. 2. Add on_error field to the base class, setting it to None by default, if the class's user does not need this field. -- Victor Porton - htt

Re: Is this pythonic?

Chris Angelico : > On Thu, Nov 24, 2016 at 10:14 PM, Marko Rauhamaa wrote: >> When you use threads, you call read(2) in the blocking mode. Then the >> read(2) operation will block "for ever." There's no clean way to >> cancel the system call. > > Signals will

Re: Is this pythonic?

On Thu, Nov 24, 2016 at 10:14 PM, Marko Rauhamaa wrote: > When you use threads, you call read(2) in the blocking mode. Then the > read(2) operation will block "for ever." There's no clean way to cancel > the system call. Signals will usually interrupt system calls, causing them

Re: Is this pythonic?

Chris Angelico : > On Thu, Nov 24, 2016 at 9:59 PM, Marko Rauhamaa wrote: >> Chris Angelico : >>> A coroutine can be abandoned at an await point, but the >>> currently-executed call is still going to complete (usually); >> >> I don't quite

Re: Is this pythonic?

On Thu, Nov 24, 2016 at 9:59 PM, Marko Rauhamaa wrote: > Chris Angelico : > >> On Thu, Nov 24, 2016 at 7:39 PM, Marko Rauhamaa wrote: >>> * Coroutines can be killed, threads cannot. >> >> Not strictly true. A coroutine can be abandoned at an

Re: Is this pythonic?

Chris Angelico : > On Thu, Nov 24, 2016 at 7:39 PM, Marko Rauhamaa wrote: >> * Coroutines can be killed, threads cannot. > > Not strictly true. A coroutine can be abandoned at an await point, but > the currently-executed call is still going to complete

Re: Is this pythonic?

On Thu, Nov 24, 2016 at 7:39 PM, Marko Rauhamaa wrote: > * Coroutines can be killed, threads cannot. > Not strictly true. A coroutine can be abandoned at an await point, but the currently-executed call is still going to complete (usually); a thread can be killed, but certain

Re: Is this pythonic?

"Frank Millman" : > "Steven D'Aprano" wrote in message > news:58368358$0$1513$c3e8da3$54964...@news.astraweb.com... >> I'm a newbie to asyncio, but if I were doing this using threads, [...] > > To me, the beauty of asyncio (or I suppose async in general) is that I > don't

Re: Is this pythonic?

"Steven D'Aprano" wrote in message news:58368358$0$1513$c3e8da3$54964...@news.astraweb.com... On Thursday 24 November 2016 15:55, Frank Millman wrote: > "Steve D'Aprano" wrote in message > news:583653bb$0$1603$c3e8da3$54964...@news.astraweb.com... > >> Even if the computation of the

Re: Is this pythonic?

On Thursday 24 November 2016 15:55, Frank Millman wrote: > "Steve D'Aprano" wrote in message > news:583653bb$0$1603$c3e8da3$54964...@news.astraweb.com... > >> Even if the computation of the memoised value is done asynchronously, you >> can easily split the computation off to a separate method

Re: Is this pythonic?

"Steve D'Aprano" wrote in message news:583653bb$0$1603$c3e8da3$54964...@news.astraweb.com... Even if the computation of the memoised value is done asynchronously, you can easily split the computation off to a separate method (as you already talked about doing!) and make getval() block until

Re: Is this pythonic?

On Wed, 23 Nov 2016 10:11 pm, Frank Millman wrote: > Gah! The law of unintended consequences strikes again! > > As I mentioned, the class in question represents a database column. Yes, you mentioned that. > A > separate class represents a database row. I have a __str__() method on the >

Re: Is this pythonic?

On Wed, 23 Nov 2016 11:27 pm, Frank Millman wrote: > It is a bit like quantum theory. I have no way of telling whether the > computation has been carried out without looking at it, but the act of > looking at it triggers the computation. I can tell, of course, by looking > at the underlying

Re: Is this pythonic?

Frank Millman wrote: For the time being I will use 'print(await obj.__str__())', as this is a good compromise. It seems more like a very *bad* compromise to me. I can't see how this gains you anything over just doing print(await obj.getvalue()), and you lose the ability to do anything that

Re: Is this pythonic?

On 2016-11-23 22:15, Steve D'Aprano wrote: > On Wed, 23 Nov 2016 08:10 pm, Frank Millman wrote: > > The class has a getval() method to return the current value. > > > > Usually the value is stored in the instance, and can be returned > > immediately, but sometimes it has to be computed, incurring

Re: Is this pythonic?

"Chris Angelico" wrote in message news:CAPTjJmqGEwHPVyrR+Ti9bV=S5MsLt3nquF4TvE=xpees188...@mail.gmail.com... On Wed, Nov 23, 2016 at 11:27 PM, Frank Millman wrote: > > @Chris >> >> This strongly suggests that str(x) is the wrong way to get the >> information. You

Re: Is this pythonic?

On Wed, Nov 23, 2016 at 11:27 PM, Frank Millman wrote: > > @Chris >> >> This strongly suggests that str(x) is the wrong way to get the >> information. You shouldn't be doing database requests inside __str__ >> or __repr__. > > > I guess you are right, but still it is a pity.

Re: Is this pythonic?

"Frank Millman" wrote in message news:o13meh$p2g$1...@blaine.gmane.org... 3. When instantiating an object, check if it would need computation - if computation_required: self.getval = self._getval_with_comp else: self.getval = self._getval 4. In _getval_with_comp,

Re: Is this pythonic?

Frank Millman wrote: > Hi all > > Sometimes I write something that I think is quite clever, but later on I > look at it and ask 'What was I thinking?'. > > I have just come up with a 'clever' solution to a problem. Would this > cause raised eyebrows if you were reviewing this? > > I have a

Re: Is this pythonic?

On Wed, Nov 23, 2016 at 10:11 PM, Frank Millman wrote: > Gah! The law of unintended consequences strikes again! > > As I mentioned, the class in question represents a database column. A > separate class represents a database row. I have a __str__() method on the > 'row' class

Re: Is this pythonic?

On Wed, 23 Nov 2016 08:10 pm, Frank Millman wrote: [...] > The class has a getval() method to return the current value. > > Usually the value is stored in the instance, and can be returned > immediately, but sometimes it has to be computed, incurring further > database lookups. This is called

Re: Is this pythonic?

"Marko Rauhamaa" wrote in message news:87inrer0dl@elektro.pacujo.net... "Frank Millman" : > 3. When instantiating an object, check if it would need computation - >if computation_required: >self.getval = self._getval_with_comp >else: >self.getval

Re: Is this pythonic?

"Marko Rauhamaa" wrote in message news:87inrer0dl@elektro.pacujo.net... "Frank Millman" : > What is the verdict? -1, 0, or +1? Perfectly cromulent, run-of-the-mill Python code. A new word to add to my vocabulary - thanks :-) Frank --

Re: Is this pythonic?

"Frank Millman" : > 3. When instantiating an object, check if it would need computation - >if computation_required: >self.getval = self._getval_with_comp >else: >self.getval = self._getval > > 4. In _getval_with_comp, perform the computation, then add

Is this pythonic?

Hi all Sometimes I write something that I think is quite clever, but later on I look at it and ask 'What was I thinking?'. I have just come up with a 'clever' solution to a problem. Would this cause raised eyebrows if you were reviewing this? I have a class that represents a single

Creating A Pythonic ctypes Binding

ctypes is a wonderful library. If you need to create a Python binding for some library that doesn’t already have one, you should look at ctypes, rather than writing an extension module in C or C++. The odds are, a pure Python implementation using

Re: Creating A Pythonic API Binding

On Wednesday 08 June 2016 12:31, Lawrence D’Oliveiro wrote: > The wrong way: [...] > The right way : That's quite good. A few minor issues: I don't understand why you have a method that returns files called "get_children". And I would expect that if you passed a

Creating A Pythonic API Binding

The wrong way: ldo@theon:~> python2 Python 2.7.11+ (default, May 9 2016, 15:54:33) [GCC 5.3.1 20160429] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import pymtp >>> mtp = pymtp.MTP() >>> mtp.connect() Device 0 (VID=04e8 and

Re: Pythonic style

On Fri, 29 Apr 2016 10:48 am, Gregory Ewing wrote: > MRAB wrote: > >> Is it worthy of being in the Zen of Python? > > +1. Maybe something along the lines of: > > Dunder methods are for defining, not calling. > Unless you're a dunderhead[1]. > > [1] Meant in the sense of an enthusiast,

Re: Pythonic style

On Fri, Apr 29, 2016 at 4:12 PM, Gregory Ewing wrote: > Chris Angelico wrote: >> >> I thought the twentieth zen would never be found? > > > Yes. This will have to be numbered the 21st zen > to maintain that invariant. > Python for the 21st Century. In a hundred

Re: Pythonic style

Chris Angelico wrote: I thought the twentieth zen would never be found? Yes. This will have to be numbered the 21st zen to maintain that invariant. -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: Pythonic style

On Fri, Apr 29, 2016 at 10:48 AM, Gregory Ewing wrote: > MRAB wrote: > >> Is it worthy of being in the Zen of Python? > > > +1. Maybe something along the lines of: > >Dunder methods are for defining, not calling. >Unless you're a dunderhead[1]. > > [1] Meant

Re: Pythonic style

MRAB wrote: Is it worthy of being in the Zen of Python? +1. Maybe something along the lines of: Dunder methods are for defining, not calling. Unless you're a dunderhead[1]. [1] Meant in the sense of an enthusiast, cf. gearhead. -- Greg --

Re: Pythonic style

On Thu, Apr 28, 2016, at 01:16, Rustom Mody wrote: > On Thursday, April 28, 2016 at 9:26:21 AM UTC+5:30, Chris Angelico wrote: > > My rule of thumb is: Dunders are for defining, not for calling. It's > > not a hard-and-fast rule, but it'll get you through 99%+ of > > situations. > > Neat and

Re: Dunder docs again (was Pythonic style)

On 2016-04-28 13:25, Marko Rauhamaa wrote: MRAB <pyt...@mrabarnett.plus.com>: 'pythonic-ness'? Surely it's 'pythonicity'! :-) Doubt it: Full Definition of generic [...] —generically \-i-k(ə-)lē\ adverb —genericness noun http://www.merriam-webster.com/dictionary/generic>

Re: Dunder docs again (was Pythonic style)

MRAB <pyt...@mrabarnett.plus.com>: > 'pythonic-ness'? Surely it's 'pythonicity'! :-) Doubt it: Full Definition of generic [...] —generically \-i-k(ə-)lē\ adverb —genericness noun http://www.merriam-webster.com/dictionary/generic> Marko -- https://mail.python.org/mail

Re: Dunder docs again (was Pythonic style)

oorly documented, especially when compared to their 'pythonic-ness'. Ive spoken of this on and off, eg https://mail.python.org/pipermail/python-list/2015-May/691329.html 'pythonic-ness'? Surely it's 'pythonicity'! :-) -- https://mail.python.org/mailman/listinfo/python-list

Dunder docs again (was Pythonic style)

dunder methods are poorly documented, especially when compared to their 'pythonic-ness'. Ive spoken of this on and off, eg https://mail.python.org/pipermail/python-list/2015-May/691329.html -- https://mail.python.org/mailman/listinfo/python-list

Re: Pythonic style

On 2016-04-28 06:16, Rustom Mody wrote: On Thursday, April 28, 2016 at 9:26:21 AM UTC+5:30, Chris Angelico wrote: My rule of thumb is: Dunders are for defining, not for calling. It's not a hard-and-fast rule, but it'll get you through 99%+ of situations. Neat and clever. Should get in the

Re: Pythonic style

On Thursday 28 April 2016 13:23, Ben Finney wrote: > Christopher Reimer writes: > >> In short, my original code before I turned it into a separate >> dictionary. *sigh* > > No, I think that misses the points that were being made. The discussion > you're talking

Re: Pythonic style

On Thursday, April 28, 2016 at 9:26:21 AM UTC+5:30, Chris Angelico wrote: > My rule of thumb is: Dunders are for defining, not for calling. It's > not a hard-and-fast rule, but it'll get you through 99%+ of > situations. Neat and clever. Should get in the docs somewhere --

Re: Pythonic style

On 4/27/2016 8:52 PM, Ethan Furman wrote: The point Ben was trying to make is this: you should never* call __dunder__ methods in normal code; there is no need to do so: - use len(), not __len__() - use next(), not __next__() - use some_instance.an_attribute, not

Re: Pythonic style

On 4/27/2016 8:23 PM, Ben Finney wrote: If you want items in a mapping, explicitly use a Python ‘dict’ instance. If you want attributes that describe an object, explicitly use attributes of that object. Deliberately choose which one makes more sense. Okay, that makes sense. Thank you, Chris

Re: Pythonic style

On Thu, Apr 28, 2016 at 1:52 PM, Ethan Furman wrote: > > The point Ben was trying to make is this: you should never* call __dunder__ > methods in normal code; there is no need to do so: > > - use len(), not __len__() > - use next(), not __next__() > - use

Re: Pythonic style

On 04/27/2016 08:07 PM, Christopher Reimer wrote: On 4/27/2016 7:07 PM, Ben Finney wrote: >> Ian Kelly wrote: self.__dict__ = {'key', 'value'} is essentially equivalent to: self.key = value >> I would say the latter is more Pythonic, because it: >> &g

Re: Pythonic style

Christopher Reimer writes: > In short, my original code before I turned it into a separate > dictionary. *sigh* No, I think that misses the points that were being made. The discussion you're talking about was *not* to say “attribute access is better than

Re: Pythonic style (was: Differences between Class(Object) and Class(Dict) for dictionary usage?)

On 4/27/2016 7:07 PM, Ben Finney wrote: I would say the latter is more Pythonic, because it: * Better conveys the intention (“set the value of the ‘self.key’ attribute”). * Uses the built-in mechanisms of Python (don't invoke magic attributes, instead use the system that makes use

Pythonic style (was: Differences between Class(Object) and Class(Dict) for dictionary usage?)

Christopher Reimer <christopher_rei...@icloud.com> writes: > On 4/27/2016 7:33 AM, Ian Kelly wrote: > > > self.__dict__ = {'key', 'value'} > > > > self.key = value > > Which expression is Pythonic? (Note that assignment is not an expression in Python

Re: Pythonic love

justin walters writes: > Sorry about the top posting. I'm new to mailing lists. I should just reply > to the python-list@python.org address then? > > Also, thank you for the generator clarification. > On Mar 8, 2016 9:09 AM, "jmp" wrote: ^

Re: Pythonic love

Sorry about the top posting. I'm new to mailing lists. I should just reply to the python-list@python.org address then? Also, thank you for the generator clarification. On Mar 8, 2016 9:09 AM, "jmp" wrote: > On 03/08/2016 05:49 PM, justin walters wrote: > >> Correct me if

Re: Pythonic love

On 03/08/2016 05:49 PM, justin walters wrote: Correct me if I'm wrong, but don't python generators usually use the yield statement so they can be used in list comprehensions? Hello, Please don't top post. Generator expressions are different from generator functions. They are both generators

Re: Pythonic love

On 08/03/2016 16:49, justin walters wrote: Correct me if I'm wrong, but don't python generators usually use the yield statement so they can be used in list comprehensions? Please don't top post on this list, thanks. -- My fellow Pythonistas, ask not what our language can do for you, ask what

Re: Pythonic love

Correct me if I'm wrong, but don't python generators usually use the yield statement so they can be used in list comprehensions? On Mar 8, 2016 5:27 AM, "jmp" wrote: > On 03/07/2016 11:51 PM, Fillmore wrote: > >> >> learning Python from Perl here. Want to do things as

Re: Pythonic love

On 03/07/2016 11:51 PM, Fillmore wrote: learning Python from Perl here. Want to do things as Pythonicly as possible. I am reading a TSV, but need to skip the first 5 lines. The following works, but wonder if there's a more pythonc way to do things. Thanks ctr = 0 with

Re: Pythonic love

On 07/03/2016 22:51, Fillmore wrote: learning Python from Perl here. Want to do things as Pythonicly as possible. I am reading a TSV, but need to skip the first 5 lines. The following works, but wonder if there's a more pythonc way to do things. Thanks ctr = 0 with

Re: Pythonic love

On 3/7/2016 6:03 PM, sohcahto...@gmail.com wrote: On a side note, your "with open..." line uses inconsistent quoting. > You have "" on one string, but '' on another. Thanks. I'll make sure I flog myself three times later tonight... -- https://mail.python.org/mailman/listinfo/python-list

Re: Pythonic love

On Mon, Mar 7, 2016 at 3:51 PM, Fillmore wrote: > > learning Python from Perl here. Want to do things as Pythonicly as possible. > > I am reading a TSV, but need to skip the first 5 lines. The following works, > but wonder if there's a more pythonc way to do things.

Re: Pythonic love

On Monday, March 7, 2016 at 2:51:50 PM UTC-8, Fillmore wrote: > learning Python from Perl here. Want to do things as Pythonicly as possible. > > I am reading a TSV, but need to skip the first 5 lines. The following > works, but wonder if there's a more pythonc way to do things. Thanks > > ctr =

Re: Pythonic love

Fillmore wrote: > > learning Python from Perl here. Want to do things as Pythonicly as possible. > > I am reading a TSV, but need to skip the first 5 lines. The following > works, but wonder if there's a more pythonc way to do things. Thanks > > ctr = 0 > with

Pythonic love

learning Python from Perl here. Want to do things as Pythonicly as possible. I am reading a TSV, but need to skip the first 5 lines. The following works, but wonder if there's a more pythonc way to do things. Thanks ctr = 0 with open(prfile,mode="rt",encoding='utf-8') as pfile: for line

Re: Fast pythonic way to process a huge integer list

On Wednesday, 6 January 2016 18:37:22 UTC-8, high5s...@gmail.com wrote: > I have a list of 163.840 integers. What is a fast & pythonic way to process > this list in 1,280 chunks of 128 integers? Thanks all for your valuable input - much appreciated! -- https://mail.python.org/mailma

Re: Fast pythonic way to process a huge integer list

high5stor...@gmail.com wrote: > I have a list of 163.840 integers. What is a fast & pythonic way to > process this list in 1,280 chunks of 128 integers? What kind of processing do you have in mind? If it is about numbercrunching use a numpy.array. This can also easily change

Fast pythonic way to process a huge integer list

I have a list of 163.840 integers. What is a fast & pythonic way to process this list in 1,280 chunks of 128 integers? -- https://mail.python.org/mailman/listinfo/python-list

Re: Fast pythonic way to process a huge integer list

On 06Jan2016 18:36, high5stor...@gmail.com <high5stor...@gmail.com> wrote: I have a list of 163.840 integers. What is a fast & pythonic way to process this list in 1,280 chunks of 128 integers? The depends. When you say "list", is it already a _python_ list?

Re: Fast pythonic way to process a huge integer list

On 1/6/2016 9:36 PM, high5stor...@gmail.com wrote: I have a list of 163.840 integers. What is a fast & pythonic way to process this list in 1,280 chunks of 128 integers? What have you tried that did not work? This is really pretty simple, but the detail depend on the meaning of 'pro

Re: Fast pythonic way to process a huge integer list

On 2016-01-06 18:36, high5stor...@gmail.com wrote: > I have a list of 163.840 integers. What is a fast & pythonic way to > process this list in 1,280 chunks of 128 integers? That's a modest list, far from huge. You have lots of options, but the following seems the most pythonic to

Re: How to handle exceptions properly in a pythonic way?

Hi, You are right. I am trying to address a few questions at the same time. As English is not my first language, I can only say that you have addressed them very well. Thanks. 1. Where to put the try/except block, inside or outside the function 2. How to deal with un-anticipated exceptions

Re: How to handle exceptions properly in a pythonic way?

Hi, > def get_html(...): > try: > ... actually go get the info > return info > except (ConnectionError, OSError, SocketError) as e: > raise ContentNotFoundError from e Personally, I never liked "early returns". I would rather used a variable and the last line in

Re: How to handle exceptions properly in a pythonic way?

> The best way is probably to do nothing at all, and let the caller handle > any exceptions. In that case every call of the get_html function has to be in the try/except block with many exceptions. Sometimes, it is enough just to know whether I managed to get the html or not. In that case, I

Re: How to handle exceptions properly in a pythonic way?

On Thu, Nov 5, 2015 at 2:41 PM, wrote: > Raising an exception forces me to put every call of the get_html function in > try/except block. > If I am returning a special value, than I can call get_html and then test the > value. > > I am not sure which approach is better.

Re: How to handle exceptions properly in a pythonic way?

> Which would you prefer? So if I am just checking for the ConnectionError in get_html and a new exception arises, I will have traceback to the get_html function showing that unhandled exception has happened. Now I have to put additional exception block for managing the new exception in the

Re: How to handle exceptions properly in a pythonic way?

在 2015年11月4日星期三 UTC-6下午10:18:33，zlju...@gmail.com写道： > > Which would you prefer? > > So if I am just checking for the ConnectionError in get_html and a new > exception arises, I will have traceback to the get_html function showing that > unhandled exception has happened. > Now I have to put

Re: How to handle exceptions properly in a pythonic way?

On Monday, 2 November 2015 21:59:45 UTC+1, Ian wrote: > I'm having a hard time understanding what question you're asking. :) I am really having a hard time to explain the problem as English is not my first language. > You > have a lot of discussion about where to handle exceptions, That's

Re: How to handle exceptions properly in a pythonic way?

On Thu, Nov 5, 2015 at 3:18 PM, wrote: >> Which would you prefer? > > So if I am just checking for the ConnectionError in get_html and a new > exception arises, I will have traceback to the get_html function showing that > unhandled exception has happened. > Now I have to

Re: How to handle exceptions properly in a pythonic way?

Hi, If I may, I feel you are tying to address a few questions at the same time, although they are related 1. Where to put the try/except block, inside or outside the function 2. How to deal with un-anticipated exceptions 3. How to keep record My personal feelings are: 1. Kind of prefer try/except

Re: How to handle exceptions properly in a pythonic way?

In <4b303213-62e2-42d4-b2f6-4fc1f6025...@googlegroups.com> zljubi...@gmail.com writes: > Let's say that I have the following simple function: > def get_html(url): > wpage = requests.get(url) > > return wpage.text > How to handle exceptions properly that can arise during execution

How to handle exceptions properly in a pythonic way?

x.html') is not None: I_am_sure_that_html_has_been_downloaded_correctly Now if I want to catch a new exception, I can catch it in get_html function, which is the only change in the program. I have read some articles that returning None is not a good approach, so I am confused. How to handle exceptions pr

<    1   2   3   4   5   6   7   8   9   10   >